From issues at jboss.org  Tue Sep  1 00:34:05 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 1 Sep 2015 00:34:05 -0400 (EDT)
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.9073.1441082045263@Atlassian.JIRA>


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

Stuart Douglas commented on WFLY-5199:
--------------------------------------

Sorry, my bad, I did not pay enough attention. 

I think 3) is fine, can you send in a PR?

> 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 00:45:06 2015
From: issues at jboss.org (Jan Martiska (JIRA))
Date: Tue, 1 Sep 2015 00:45:06 -0400 (EDT)
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.9076.1441082706062@Atlassian.JIRA>


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

Jan Martiska updated WFLY-5199:
-------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/7998)


> 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 01:13:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Sep 2015 01:13:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.9098.1441084385368@Atlassian.JIRA>


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

Bela Ban updated JGRP-1957:
---------------------------
    Fix Version/s: 3.6.5


> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 01:32:05 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 1 Sep 2015 01:32:05 -0400 (EDT)
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.1441085512510@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583360.1441085512000.9115.1441085525519@Atlassian.JIRA>

Stuart Douglas created WFLY-5243:
------------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 01:35:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 01:35:05 -0400 (EDT)
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.1441085658390@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583361.1441085658000.9120.1441085705330@Atlassian.JIRA>

Rob Stryker created WFLY-5244:
---------------------------------

             Summary: 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


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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 01:40:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 01:40:05 -0400 (EDT)
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.9122.1441086005299@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5244:
-----------------------------------

If it turns out that arquillian_1_0.xsd is modified to fix this bug by adding the property element to the schema,  (rather than removing the property from the quickstart) I'd like to request that the schema be added to http://www.jboss.org/schema/jbossas/ for easy mirroring of all of our relevant schema into JBoss Tools. 

> 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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 01:45:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 01:45:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5245) [Quickstart]
 application-component-2 fails xml validation in eclipse
In-Reply-To: <JIRA.12583363.1441086268000@Atlassian.JIRA>
References: <JIRA.12583363.1441086268000@Atlassian.JIRA>
	<JIRA.12583363.1441086268704@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583363.1441086268000.9126.1441086305251@Atlassian.JIRA>

Rob Stryker created WFLY-5245:
---------------------------------

             Summary: [Quickstart] application-component-2 fails xml validation in eclipse
                 Key: WFLY-5245
                 URL: https://issues.jboss.org/browse/WFLY-5245
             Project: WildFly
          Issue Type: Bug
            Reporter: Rob Stryker
            Assignee: Jason Greene


jts/application-component-2/src/main/resources/META-INF/jboss-ejb3.xml  file includes:

{code}
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:iiop="urn:iiop"
               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-ejb3-2_0.xsd
                  http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
                  urn:iiop jboss-ejb-iiop_1_0.xsd"
{code}

The line  "urn:iiop jboss-ejb-iiop_1_0.xsd"  is clearly problematic and provides no evidence of where it might pull this xsd from. 

I suggest replacing it with

                  urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 02:08:05 2015
From: issues at jboss.org (Pravasis Pattnaik (JIRA))
Date: Tue, 1 Sep 2015 02:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-900)
 java.lang.IncompatibleClassChangeError error while using HashSets
In-Reply-To: <JIRA.12583366.1441087631000@Atlassian.JIRA>
References: <JIRA.12583366.1441087631000@Atlassian.JIRA>
	<JIRA.12583366.1441087631489@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583366.1441087631000.9158.1441087685463@Atlassian.JIRA>

Pravasis Pattnaik created DROOLS-900:
----------------------------------------

             Summary: java.lang.IncompatibleClassChangeError error while using HashSets
                 Key: DROOLS-900
                 URL: https://issues.jboss.org/browse/DROOLS-900
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 5.6.0.Final
            Reporter: Pravasis Pattnaik
            Assignee: Mario Fusco
            Priority: Minor
         Attachments: compiled-drl.txt, req.txt

In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(x) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(x) it fixes everything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 02:08:05 2015
From: issues at jboss.org (Pravasis Pattnaik (JIRA))
Date: Tue, 1 Sep 2015 02:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-900)
 java.lang.IncompatibleClassChangeError error while using HashSets
In-Reply-To: <JIRA.12583366.1441087631000@Atlassian.JIRA>
References: <JIRA.12583366.1441087631000@Atlassian.JIRA>
	<JIRA.12583366.1441087631000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583366.1441087631000.9161.1441087685778@Atlassian.JIRA>


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

Pravasis Pattnaik updated DROOLS-900:
-------------------------------------
    Workaround Description: If I change it to Sets.newHashSet(e1,e2,..).contains(i) it fixes everything.  (was: If I change it to Sets.newHashSet(e1,e2,..).contains(x) it fixes everything.)


> java.lang.IncompatibleClassChangeError error while using HashSets
> -----------------------------------------------------------------
>
>                 Key: DROOLS-900
>                 URL: https://issues.jboss.org/browse/DROOLS-900
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Pravasis Pattnaik
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: compiled-drl.txt, req.txt
>
>
> In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(x) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(x) it fixes everything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 02:09:05 2015
From: issues at jboss.org (Pravasis Pattnaik (JIRA))
Date: Tue, 1 Sep 2015 02:09:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-900)
 java.lang.IncompatibleClassChangeError error while using HashSets
In-Reply-To: <JIRA.12583366.1441087631000@Atlassian.JIRA>
References: <JIRA.12583366.1441087631000@Atlassian.JIRA>
	<JIRA.12583366.1441087631000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583366.1441087631000.9165.1441087745359@Atlassian.JIRA>


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

Pravasis Pattnaik updated DROOLS-900:
-------------------------------------
    Workaround Description: If I change it to Sets.newHashSet(e1,e2,..).contains(input) it fixes everything.  (was: If I change it to Sets.newHashSet(e1,e2,..).contains(i) it fixes everything.)


> java.lang.IncompatibleClassChangeError error while using HashSets
> -----------------------------------------------------------------
>
>                 Key: DROOLS-900
>                 URL: https://issues.jboss.org/browse/DROOLS-900
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Pravasis Pattnaik
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: compiled-drl.txt, req.txt
>
>
> In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(x) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(x) it fixes everything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 02:09:05 2015
From: issues at jboss.org (Pravasis Pattnaik (JIRA))
Date: Tue, 1 Sep 2015 02:09:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-900)
 java.lang.IncompatibleClassChangeError error while using HashSets
In-Reply-To: <JIRA.12583366.1441087631000@Atlassian.JIRA>
References: <JIRA.12583366.1441087631000@Atlassian.JIRA>
	<JIRA.12583366.1441087631000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583366.1441087631000.9168.1441087745500@Atlassian.JIRA>


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

Pravasis Pattnaik updated DROOLS-900:
-------------------------------------
    Description: In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(input) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(input) it fixes everything.  (was: In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(x) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(x) it fixes everything.)


> java.lang.IncompatibleClassChangeError error while using HashSets
> -----------------------------------------------------------------
>
>                 Key: DROOLS-900
>                 URL: https://issues.jboss.org/browse/DROOLS-900
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Pravasis Pattnaik
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: compiled-drl.txt, req.txt
>
>
> In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(input) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(input) it fixes everything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 02:20:05 2015
From: issues at jboss.org (Weinan Li (JIRA))
Date: Tue, 1 Sep 2015 02:20:05 -0400 (EDT)
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.1441088395991@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583367.1441088395000.9173.1441088405285@Atlassian.JIRA>

Weinan Li created WFLY-5246:
-------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 02:57:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 02:57:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5247)
 wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in
 eclipse
In-Reply-To: <JIRA.12583372.1441090578000@Atlassian.JIRA>
References: <JIRA.12583372.1441090578000@Atlassian.JIRA>
	<JIRA.12583372.1441090578806@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583372.1441090578000.9207.1441090625386@Atlassian.JIRA>

Rob Stryker created WFLY-5247:
---------------------------------

             Summary: wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in eclipse
                 Key: WFLY-5247
                 URL: https://issues.jboss.org/browse/WFLY-5247
             Project: WildFly
          Issue Type: Bug
            Reporter: Rob Stryker
            Assignee: Jason Greene


wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate. 

The xml file jboss-ejb3.xml file inside the project has the following content:

{code}
<?xml version="1.0" encoding="UTF-8"?>
<!--
    JBoss, Home of Professional Open Source
    Copyright 2013, Red Hat, Inc. and/or its affiliates, and individual
    contributors by the @authors tag. See the copyright.txt in the
    distribution for a full listing of individual contributors.

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
-->
<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:s="urn:security"
    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">
    <enterprise-beans>
    </enterprise-beans>
    <assembly-descriptor>
    </assembly-descriptor>
</jboss:ejb-jar>
{code}

Unfortunately, the element "enterprise-beans" is not allowed to be empty. 

A solution is to remove the empty "enterprise-beans" element. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 03:27:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 03:27:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5247)
 wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in
 eclipse
In-Reply-To: <JIRA.12583372.1441090578000@Atlassian.JIRA>
References: <JIRA.12583372.1441090578000@Atlassian.JIRA>
	<JIRA.12583372.1441090578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583372.1441090578000.9278.1441092425232@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5247:
-----------------------------------

A second problem with this file is in the namespace imports. 

{code}
    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"
{code}

The URL http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd   should be changed to http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/ejb-jar_3_1.xsd  since there's a current bug in eclipse that does not follow redirects. 

> wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in eclipse
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5247
>                 URL: https://issues.jboss.org/browse/WFLY-5247
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate. 
> The xml file jboss-ejb3.xml file inside the project has the following content:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
>     JBoss, Home of Professional Open Source
>     Copyright 2013, Red Hat, Inc. and/or its affiliates, and individual
>     contributors by the @authors tag. See the copyright.txt in the
>     distribution for a full listing of individual contributors.
>     Licensed under the Apache License, Version 2.0 (the "License");
>     you may not use this file except in compliance with the License.
>     You may obtain a copy of the License at
>     http://www.apache.org/licenses/LICENSE-2.0
>     Unless required by applicable law or agreed to in writing, software
>     distributed under the License is distributed on an "AS IS" BASIS,
>     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>     See the License for the specific language governing permissions and
>     limitations under the License.
> -->
> <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:s="urn:security"
>     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">
>     <enterprise-beans>
>     </enterprise-beans>
>     <assembly-descriptor>
>     </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> Unfortunately, the element "enterprise-beans" is not allowed to be empty. 
> A solution is to remove the empty "enterprise-beans" element. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 03:41:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 03:41:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5248)
 wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in
 eclipse
In-Reply-To: <JIRA.12583384.1441093256000@Atlassian.JIRA>
References: <JIRA.12583384.1441093256000@Atlassian.JIRA>
	<JIRA.12583384.1441093256309@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583384.1441093256000.9312.1441093265388@Atlassian.JIRA>

Rob Stryker created WFLY-5248:
---------------------------------

             Summary: wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in eclipse
                 Key: WFLY-5248
                 URL: https://issues.jboss.org/browse/WFLY-5248
             Project: WildFly
          Issue Type: Bug
            Reporter: Rob Stryker
            Assignee: Jason Greene


The quickstart wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate.   The reason seems to be as follows:

1)  jboss-ejb3.xml imports the xmlns:ci ="urn:container-interceptors:1.0" namespace. 

2) boss-ejb-container-interceptors_1_0.xsd imports jboss-ejb3-spec-2_0.xsd namespace  as follows:

{code}
<xs:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
{code}

3)  jboss-ejb3-spec-2_0.xsd imports jboss-ejb3-2_0.xsd as follows:

{code}
<xs:import namespace="http://www.jboss.com/xml/ns/javaee" schemaLocation="jboss-ejb3-2_0.xsd"/>
{code}

The use of a relative path in step 3 breaks the eclipse validator. It would be best to use full urls that point to the actual xsd file. 

This fix will most likely require:
  1) Changes to   jboss-ejb3-spec-2_0.xsd  in whatever repository it lives in
  2) Changes to   jboss-ejb3-spec-2_0.xsd on http://www.jboss.org/schema/jbossas/
  3) Changes to jboss-ejb3-spec-2_0.xsd  inside jbosstools, which typically clones all updated files living at http://www.jboss.org/schema/jbossas/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 03:47:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 03:47:05 -0400 (EDT)
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.1441093591277@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583388.1441093591000.9336.1441093625946@Atlassian.JIRA>

Rob Stryker created WFLY-5249:
---------------------------------

             Summary: 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


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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 04:02:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 04:02:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5250)
 wildfly-jts-application-component-2 fails to validate
In-Reply-To: <JIRA.12583394.1441094489000@Atlassian.JIRA>
References: <JIRA.12583394.1441094489000@Atlassian.JIRA>
	<JIRA.12583394.1441094489246@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583394.1441094489000.9371.1441094525363@Atlassian.JIRA>

Rob Stryker created WFLY-5250:
---------------------------------

             Summary: wildfly-jts-application-component-2 fails to validate
                 Key: WFLY-5250
                 URL: https://issues.jboss.org/browse/WFLY-5250
             Project: WildFly
          Issue Type: Bug
            Reporter: Rob Stryker
            Assignee: Jason Greene


The above quickstart fails to validate in eclipse. It has the following lines in it:

{code}
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:iiop="urn:iiop"
               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-ejb3-2_0.xsd
                  http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
                  urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
               version="3.1"
               impl-version="2.0">
    <assembly-descriptor>
        <iiop:iiop>
            <ejb-name>InvoiceManagerEJBImpl</ejb-name>
            <iiop:binding-name>jts-quickstart/InvoiceManagerEJBImpl</iiop:binding-name>
        </iiop:iiop>
    </assembly-descriptor>
</jboss:ejb-jar>
{code}


The key line to note is:

{code}
                  urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
{code}

Using relative paths cannot guarantee the resolution of a dependent schema. I suggest you replace this with:

{code}
urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
{code}

However, even once that is fixed, the quickstart still has other problems. For one example:

{code}
cvc-complex-type.2.4.a: Invalid content was found starting with element 'iiop:iiop'. One of '{"http://
 java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":method-
 permission, "http://java.sun.com/xml/ns/javaee":container-transaction, "http://java.sun.com/xml/ns/
 javaee":interceptor-binding, "http://java.sun.com/xml/ns/javaee":message-destination, "http://
 java.sun.com/xml/ns/javaee":exclude-list, "http://java.sun.com/xml/ns/javaee":application-
 exception}' is expected.
{code}

I strongly suggest someone test the quickstart in JBossTools and help come up with a descriptor that passes validation. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 04:02:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 04:02:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5250)
 wildfly-jts-application-component-2 quickstart fails to validate in eclipse
In-Reply-To: <JIRA.12583394.1441094489000@Atlassian.JIRA>
References: <JIRA.12583394.1441094489000@Atlassian.JIRA>
	<JIRA.12583394.1441094489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583394.1441094489000.9374.1441094525549@Atlassian.JIRA>


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

Rob Stryker updated WFLY-5250:
------------------------------
    Summary: wildfly-jts-application-component-2 quickstart fails to validate in eclipse  (was: wildfly-jts-application-component-2 fails to validate)


> wildfly-jts-application-component-2 quickstart fails to validate in eclipse
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5250
>                 URL: https://issues.jboss.org/browse/WFLY-5250
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> The above quickstart fails to validate in eclipse. It has the following lines in it:
> {code}
> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
>                xmlns="http://java.sun.com/xml/ns/javaee"
>                xmlns:iiop="urn:iiop"
>                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-ejb3-2_0.xsd
>                   http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
>                   urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
>                version="3.1"
>                impl-version="2.0">
>     <assembly-descriptor>
>         <iiop:iiop>
>             <ejb-name>InvoiceManagerEJBImpl</ejb-name>
>             <iiop:binding-name>jts-quickstart/InvoiceManagerEJBImpl</iiop:binding-name>
>         </iiop:iiop>
>     </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> The key line to note is:
> {code}
>                   urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
> {code}
> Using relative paths cannot guarantee the resolution of a dependent schema. I suggest you replace this with:
> {code}
> urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
> {code}
> However, even once that is fixed, the quickstart still has other problems. For one example:
> {code}
> cvc-complex-type.2.4.a: Invalid content was found starting with element 'iiop:iiop'. One of '{"http://
>  java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":method-
>  permission, "http://java.sun.com/xml/ns/javaee":container-transaction, "http://java.sun.com/xml/ns/
>  javaee":interceptor-binding, "http://java.sun.com/xml/ns/javaee":message-destination, "http://
>  java.sun.com/xml/ns/javaee":exclude-list, "http://java.sun.com/xml/ns/javaee":application-
>  exception}' is expected.
> {code}
> I strongly suggest someone test the quickstart in JBossTools and help come up with a descriptor that passes validation. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 04:15:07 2015
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Tue, 1 Sep 2015 04:15:07 -0400 (EDT)
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.1441095259341@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583398.1441095259000.9427.1441095307226@Atlassian.JIRA>

Alessio Soldano created WFLY-5251:
-------------------------------------

             Summary: 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 04:56:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 04:56:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5250)
 wildfly-jts-application-component-2 quickstart fails to validate in eclipse
In-Reply-To: <JIRA.12583394.1441094489000@Atlassian.JIRA>
References: <JIRA.12583394.1441094489000@Atlassian.JIRA>
	<JIRA.12583394.1441094489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583394.1441094489000.9669.1441097765312@Atlassian.JIRA>


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

Rob Stryker updated WFLY-5250:
------------------------------
    Description: 
The above quickstart fails to validate in eclipse. It has the following lines in it:

{code}
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:iiop="urn:iiop"
               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-ejb3-2_0.xsd
                  http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
                  urn:iiop jboss-ejb-iiop_1_0.xsd"
               version="3.1"
               impl-version="2.0">
    <assembly-descriptor>
        <iiop:iiop>
            <ejb-name>InvoiceManagerEJBImpl</ejb-name>
            <iiop:binding-name>jts-quickstart/InvoiceManagerEJBImpl</iiop:binding-name>
        </iiop:iiop>
    </assembly-descriptor>
</jboss:ejb-jar>
{code}


The key line to note is:

{code}
                  urn:iiop jboss-ejb-iiop_1_0.xsd"
{code}

Using relative paths cannot guarantee the resolution of a dependent schema. I suggest you replace this with:

{code}
urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
{code}

However, even once that is fixed, the quickstart still has other problems. For one example:

{code}
cvc-complex-type.2.4.a: Invalid content was found starting with element 'iiop:iiop'. One of '{"http://
 java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":method-
 permission, "http://java.sun.com/xml/ns/javaee":container-transaction, "http://java.sun.com/xml/ns/
 javaee":interceptor-binding, "http://java.sun.com/xml/ns/javaee":message-destination, "http://
 java.sun.com/xml/ns/javaee":exclude-list, "http://java.sun.com/xml/ns/javaee":application-
 exception}' is expected.
{code}

I strongly suggest someone test the quickstart in JBossTools and help come up with a descriptor that passes validation. 

  was:
The above quickstart fails to validate in eclipse. It has the following lines in it:

{code}
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:iiop="urn:iiop"
               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-ejb3-2_0.xsd
                  http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
                  urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
               version="3.1"
               impl-version="2.0">
    <assembly-descriptor>
        <iiop:iiop>
            <ejb-name>InvoiceManagerEJBImpl</ejb-name>
            <iiop:binding-name>jts-quickstart/InvoiceManagerEJBImpl</iiop:binding-name>
        </iiop:iiop>
    </assembly-descriptor>
</jboss:ejb-jar>
{code}


The key line to note is:

{code}
                  urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
{code}

Using relative paths cannot guarantee the resolution of a dependent schema. I suggest you replace this with:

{code}
urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
{code}

However, even once that is fixed, the quickstart still has other problems. For one example:

{code}
cvc-complex-type.2.4.a: Invalid content was found starting with element 'iiop:iiop'. One of '{"http://
 java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":method-
 permission, "http://java.sun.com/xml/ns/javaee":container-transaction, "http://java.sun.com/xml/ns/
 javaee":interceptor-binding, "http://java.sun.com/xml/ns/javaee":message-destination, "http://
 java.sun.com/xml/ns/javaee":exclude-list, "http://java.sun.com/xml/ns/javaee":application-
 exception}' is expected.
{code}

I strongly suggest someone test the quickstart in JBossTools and help come up with a descriptor that passes validation. 



> wildfly-jts-application-component-2 quickstart fails to validate in eclipse
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5250
>                 URL: https://issues.jboss.org/browse/WFLY-5250
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> The above quickstart fails to validate in eclipse. It has the following lines in it:
> {code}
> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
>                xmlns="http://java.sun.com/xml/ns/javaee"
>                xmlns:iiop="urn:iiop"
>                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-ejb3-2_0.xsd
>                   http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
>                   urn:iiop jboss-ejb-iiop_1_0.xsd"
>                version="3.1"
>                impl-version="2.0">
>     <assembly-descriptor>
>         <iiop:iiop>
>             <ejb-name>InvoiceManagerEJBImpl</ejb-name>
>             <iiop:binding-name>jts-quickstart/InvoiceManagerEJBImpl</iiop:binding-name>
>         </iiop:iiop>
>     </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> The key line to note is:
> {code}
>                   urn:iiop jboss-ejb-iiop_1_0.xsd"
> {code}
> Using relative paths cannot guarantee the resolution of a dependent schema. I suggest you replace this with:
> {code}
> urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"
> {code}
> However, even once that is fixed, the quickstart still has other problems. For one example:
> {code}
> cvc-complex-type.2.4.a: Invalid content was found starting with element 'iiop:iiop'. One of '{"http://
>  java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":method-
>  permission, "http://java.sun.com/xml/ns/javaee":container-transaction, "http://java.sun.com/xml/ns/
>  javaee":interceptor-binding, "http://java.sun.com/xml/ns/javaee":message-destination, "http://
>  java.sun.com/xml/ns/javaee":exclude-list, "http://java.sun.com/xml/ns/javaee":application-
>  exception}' is expected.
> {code}
> I strongly suggest someone test the quickstart in JBossTools and help come up with a descriptor that passes validation. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 05:53:05 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 1 Sep 2015 05:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5252) Fix MDB20TestCase
In-Reply-To: <JIRA.12583412.1441101182000@Atlassian.JIRA>
References: <JIRA.12583412.1441101182000@Atlassian.JIRA>
	<JIRA.12583412.1441101182217@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583412.1441101182000.9812.1441101185437@Atlassian.JIRA>

Jeff Mesnil created WFLY-5252:
---------------------------------

             Summary: Fix MDB20TestCase
                 Key: WFLY-5252
                 URL: https://issues.jboss.org/browse/WFLY-5252
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 10.0.0.Beta2
            Reporter: Jeff Mesnil
            Priority: Minor
             Fix For: 10.0.0.CR1


The MDB20TestCase is failing often on our test suite with the error:

{noformat}
java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueB]
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertNotNull(Assert.java:621)
    at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:118)
{noformat}

>From the logs, only 1 of the MDB receives the message sent to the topic.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 05:59:05 2015
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Tue, 1 Sep 2015 05:59:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-1972) Show DRL for decision
	tables
In-Reply-To: <JIRA.12379968.1234854146000@Atlassian.JIRA>
References: <JIRA.12379968.1234854146000@Atlassian.JIRA>
	<JIRA.12379968.1234854146000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12379968.1234854146000.9834.1441101545316@Atlassian.JIRA>


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

Toni Rikkola resolved JBRULES-1972.
-----------------------------------
    Resolution: Done


Just happened to run into this while searching for another ticket. This function is now in both guided and XLS dtables.

> Show DRL for decision tables
> ----------------------------
>
>                 Key: JBRULES-1972
>                 URL: https://issues.jboss.org/browse/JBRULES-1972
>             Project: JBRULES
>          Issue Type: Feature Request
>          Components: drools-eclipse
>            Reporter: Simon Spielmann
>             Fix For: FUTURE
>
>
> Sometimes it is very useful to see the generated drl for a decision table. Without it you can't even set breakpoints.
> I suggest to add a menu item e.g. "show drl" to the context menu for a spreadsheet file in the eclipse ide.
> I think this shouldn't be to hard to implement.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 06:13:05 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 1 Sep 2015 06:13:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-710) Make ServerOperationResolver
 handle deployment-overlays similarly to deployments
In-Reply-To: <JIRA.12572635.1432626729000@Atlassian.JIRA>
References: <JIRA.12572635.1432626729000@Atlassian.JIRA>
	<JIRA.12572635.1432626729000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572635.1432626729000.9884.1441102385337@Atlassian.JIRA>


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

Kabir Khan updated WFCORE-710:
------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR1)


> Make ServerOperationResolver handle deployment-overlays similarly to deployments
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-710
>                 URL: https://issues.jboss.org/browse/WFCORE-710
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha2
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 3.0.0.Alpha1
>
>
> Currently in domain mode a
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> results in a deployment overlay on ALL servers.
> However for deployments
> {code}
> /deployment=xxx:add(...)
> {code}
> does not get pushed to the servers. This happens when it is associated with a server group:
> {code}
> /server-group=zzz/deployment=xxx:add(...)
> {code}
> Similarly
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> should not get pushed to the servers, until we have a
> {code}
> /server-group=zzz/deployment=yyy:add(...)
> {code}
> which picks out the servers we want to have the overlay



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 06:33:05 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 1 Sep 2015 06:33:05 -0400 (EDT)
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.9964.1441103585500@Atlassian.JIRA>


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

Tomaz Cerar closed WFLY-5249.
-----------------------------
    Resolution: Rejected


hibernate3 quickstart was removed for WildFly 10 quickstarts.

> 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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 07:18:05 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 1 Sep 2015 07:18:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5160) SingletonDeployment*TestCase
	fail on RHEL7
In-Reply-To: <JIRA.12582123.1440154452000@Atlassian.JIRA>
References: <JIRA.12582123.1440154452000@Atlassian.JIRA>
	<JIRA.12582123.1440154452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582123.1440154452000.10059.1441106285414@Atlassian.JIRA>


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

Paul Ferraro commented on WFLY-5160:
------------------------------------

[~mkopecky] Evidence?

> SingletonDeployment*TestCase fail on RHEL7
> ------------------------------------------
>
>                 Key: WFLY-5160
>                 URL: https://issues.jboss.org/browse/WFLY-5160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta2
>
>
> *Description of problem:*
> * Two tests fail with "expected:<405> but was:<200>" error
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentJBossAllTestCase(SYNC-tcp)#test
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentDescriptorTestCase(SYNC-tcp)#test
> *How reproducible:*
> * RHEL7
> * IBM JDK 8, Oracle JDK 8, Open JDK 8
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dtest=SingletonDeploymentJBossAllTestCase,SingletonDeploymentDescriptorTestCase -DfailIfNoTests=false -Dts.clustering
> *Actual results:*
> {noformat}
> java.lang.AssertionError: expected:<405> but was:<200>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.junit.Assert.assertEquals(Assert.java:542)
> 	at org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentTestCase.test(SingletonDeploymentTestCase.java:84)
> 	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.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$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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 	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.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.createTestContext(ContainerEventController.java:129)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor5.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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: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: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:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No failures in test case.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Tue Sep  1 08:04:06 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 1 Sep 2015 08:04:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-811) Add module for
 org.wildfly.security.elytron-web:undertow-server
In-Reply-To: <JIRA.12577734.1436547887000@Atlassian.JIRA>
References: <JIRA.12577734.1436547887000@Atlassian.JIRA>
	<JIRA.12577734.1436547887000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577734.1436547887000.10264.1441109046162@Atlassian.JIRA>


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

Darran Lofthouse reassigned WFCORE-811:
---------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)


> Add module for org.wildfly.security.elytron-web:undertow-server
> ---------------------------------------------------------------
>
>                 Key: WFCORE-811
>                 URL: https://issues.jboss.org/browse/WFCORE-811
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Modules
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha1
>
>
> This is the module that provides the integration between Elytron and Undertow without each needing to be aware of the other.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 08:34:05 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Sep 2015 08:34:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-499) System properties are broken
 in domain mode
In-Reply-To: <JIRA.12560803.1421114086000@Atlassian.JIRA>
References: <JIRA.12560803.1421114086000@Atlassian.JIRA>
	<JIRA.12560803.1421114086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560803.1421114086000.10418.1441110845723@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFCORE-499:
------------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1257301|https://bugzilla.redhat.com/show_bug.cgi?id=1257301] from POST to MODIFIED

> System properties are broken in domain mode
> -------------------------------------------
>
>                 Key: WFCORE-499
>                 URL: https://issues.jboss.org/browse/WFCORE-499
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha15
>            Reporter: Stuart Douglas
>            Assignee: ehsavoie Hugonnet
>             Fix For: 1.0.0.Alpha17
>
>
> There seems to be some weirdness in how system properties are being propagated to domain mode servers, and in many cases they are not being applied. 
> This appears to be an issue with the boot time handling of system properties.
> The only way I could get the property to be applied was to start the server first, then add the property using boot-time=false, although even in this case the property will disappear if the domain is restarted or the server is reloaded. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 08:39:05 2015
From: issues at jboss.org (Marco Mondini (JIRA))
Date: Tue, 1 Sep 2015 08:39:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4884) The file
 javax/sql/rowset/rowset.properties is not present in
 jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
In-Reply-To: <JIRA.12577291.1436285988000@Atlassian.JIRA>
References: <JIRA.12577291.1436285988000@Atlassian.JIRA>
	<JIRA.12577291.1436285988000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577291.1436285988000.10472.1441111145659@Atlassian.JIRA>


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

Marco Mondini updated WFLY-4884:
--------------------------------
    Affects Version/s: 9.0.1.Final


> The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4884
>                 URL: https://issues.jboss.org/browse/WFLY-4884
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Final, 9.0.1.Final
>            Reporter: Marco Mondini
>            Assignee: David Lloyd
>
> jboss-javax-sql-api_7.0_spec module jar does not contains javax/sql/rowset/rowset.properties.
> Fix should be trivial, moving the file in the project from src/main/java to src/main/resources will do the job.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 08:57:05 2015
From: issues at jboss.org (Marco Mondini (JIRA))
Date: Tue, 1 Sep 2015 08:57:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4884) The file
 javax/sql/rowset/rowset.properties is not present in
 jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
In-Reply-To: <JIRA.12577291.1436285988000@Atlassian.JIRA>
References: <JIRA.12577291.1436285988000@Atlassian.JIRA>
	<JIRA.12577291.1436285988000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577291.1436285988000.10539.1441112225499@Atlassian.JIRA>


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

Marco Mondini updated WFLY-4884:
--------------------------------
    Affects Version/s: 9.x.x TBD


> The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4884
>                 URL: https://issues.jboss.org/browse/WFLY-4884
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Final, 9.0.1.Final, 9.x.x TBD
>            Reporter: Marco Mondini
>            Assignee: David Lloyd
>
> jboss-javax-sql-api_7.0_spec module jar does not contains javax/sql/rowset/rowset.properties.
> Fix should be trivial, moving the file in the project from src/main/java to src/main/resources will do the job.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 09:02:05 2015
From: issues at jboss.org (Marco Mondini (JIRA))
Date: Tue, 1 Sep 2015 09:02:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-941) The file
 javax/sql/rowset/rowset.properties is not present in
 jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
In-Reply-To: <JIRA.12583427.1441112500000@Atlassian.JIRA>
References: <JIRA.12583427.1441112500000@Atlassian.JIRA>
	<JIRA.12583427.1441112500302@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583427.1441112500000.10555.1441112525768@Atlassian.JIRA>

Marco Mondini created WFCORE-941:
------------------------------------

             Summary: The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
                 Key: WFCORE-941
                 URL: https://issues.jboss.org/browse/WFCORE-941
             Project: WildFly Core
          Issue Type: Component  Upgrade
    Affects Versions: 1.0.1.Final, 1.0.2.Final
            Reporter: Marco Mondini


Changing version of the artifact "jboss-javax-sql-api_7.0_spec" to 1.1.1.Final will fix the issue.

(see: https://issues.jboss.org/browse/WFLY-4884)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 09:03:05 2015
From: issues at jboss.org (Thomas Segismont (JIRA))
Date: Tue, 1 Sep 2015 09:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.10561.1441112585740@Atlassian.JIRA>


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

Thomas Segismont commented on JGRP-1954:
----------------------------------------

Hi, I'm the contributor of the SWIFT_PING discovery protocol. For the sake of transparency, I contributed it before joining Red Hat and it's a long time I haven't worked with Openstack+JGroups. That said, here's my opinion.

A {{ScriptEngine}} based solution sounds more appealing, as it allows to keep the protocol implementation in JGroups. It is possible to write it in a way which is compatible with both Java 7 and Java 8

{code:javascript|title=script.js}
var response = JSON.parse(json);

var result = {};

result.id = response.access.token.id;

var serviceCatalog = response.access.serviceCatalog;
for (var i = 0; i < serviceCatalog.length; i++) {
    var service = serviceCatalog[i];
    if (service.type == "object-store") {
        result.url = service.endpoints[0].publicURL;
        break;
    }
}

result;
{code}

{code:json|title=response.json}
{
  "access": {
    "token": {
      "issued_at": "2014-01-30T15:30:58.819584",
      "expires": "2014-01-31T15:30:58Z",
      "id": "aaaaa-bbbbb-ccccc-dddd",
      "tenant": {
        "description": null,
        "enabled": true,
        "id": "fc394f2ab2df4114bde39905f800dc57",
        "name": "demo"
      }
    },
    "serviceCatalog": [
      {
        "endpoints": [
          {
            "adminURL": "http://23.253.72.207:8080",
            "region": "RegionOne",
            "internalURL": "http://23.253.72.207:8080/v1/AUTH_fc394f2ab2df4114bde39905f800dc57",
            "id": "16b76b5e5b7d48039a6e4cc3129545f3",
            "publicURL": "http://23.253.72.207:8080/v1/AUTH_fc394f2ab2df4114bde39905f800dc57"
          }
        ],
        "endpoints_links": [],
        "type": "object-store",
        "name": "swift"
      }
    ],
    "user": {
      "username": "demo",
      "roles_links": [],
      "id": "9a6590b2ab024747bc2167c4e064d00d",
      "roles": [
        {
          "name": "Member"
        },
        {
          "name": "anotherrole"
        }
      ],
      "name": "demo"
    },
    "metadata": {
      "is_admin": 0,
      "roles": [
        "7598ac3c634d4c3da4b9126a5f67ca2b",
        "f95c0ab82d6045d9805033ee1fbc80d4"
      ]
    }
  }
}
{code}

{code:java|title=Parsing.java}
import java.util.Map;

import javax.script.Bindings;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.SimpleBindings;

public class Parsing {

    public static void main(String[] args) throws Exception {
        ScriptEngine engine = new ScriptEngineManager().getEngineByName("JavaScript");
        System.out.println("engine.getFactory().getEngineName() = " + engine.getFactory().getEngineName());

        String name = "script.js";
        String script = // load script from file;

        String json = // load response sample from file;

        Bindings bindings = new SimpleBindings();
        bindings.put("json", json);
        Map<String, String> result = (Map<String, String>) engine.eval(script, bindings);

        System.out.println("id = " + result.get("id"));
        System.out.println("url = " + result.get("url"));
    }
}
{code}

In the actual implementation we'd have to synchronize on the script engine because it may not be thread-safe (depends on the registered implementation).

[~nsawadsky] Can you elaborate on your security concern? In the example above, we ask the JS engine to parse a JSON string, we're not evaluating the JSON string. Doesn't that mitigate security risks?

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 09:14:05 2015
From: issues at jboss.org (Tomas Repel (JIRA))
Date: Tue, 1 Sep 2015 09:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3971) Jar Services in
 META-INF/services are not loaded from static modules
In-Reply-To: <JIRA.12554975.1413202256000@Atlassian.JIRA>
References: <JIRA.12554975.1413202256000@Atlassian.JIRA>
	<JIRA.12554975.1413202256000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554975.1413202256000.10639.1441113245783@Atlassian.JIRA>


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

Tomas Repel commented on WFLY-3971:
-----------------------------------

Hi [~lucas_k], I can confirm your workaround can be applied on my reproducer as well. Thanks.

> Jar Services in META-INF/services are not loaded from static modules
> --------------------------------------------------------------------
>
>                 Key: WFLY-3971
>                 URL: https://issues.jboss.org/browse/WFLY-3971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final, 9.0.0.Final, 10.0.0.Alpha6
>            Reporter: Tomas Repel
>            Assignee: Stuart Douglas
>
> If the web application (war) uses jar file from static module, the content of META-INF/services has no effect. If the jar is located inside WEB-INF/lib, services are loaded successfully.
> Neither adding `Dependencies: my.module.name.com services` into MANIFEST.MF nor adding `services="import"` to jboss-deployment-structure.xml works.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 10:00:06 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 1 Sep 2015 10:00:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4884) The file
 javax/sql/rowset/rowset.properties is not present in
 jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
In-Reply-To: <JIRA.12577291.1436285988000@Atlassian.JIRA>
References: <JIRA.12577291.1436285988000@Atlassian.JIRA>
	<JIRA.12577291.1436285988000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577291.1436285988000.10874.1441116006434@Atlassian.JIRA>


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

Tomaz Cerar commented on WFLY-4884:
-----------------------------------

version 2.0.0.Final already has the fix. which is already in master.

> The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4884
>                 URL: https://issues.jboss.org/browse/WFLY-4884
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Final, 9.0.1.Final, 9.x.x TBD
>            Reporter: Marco Mondini
>            Assignee: David Lloyd
>
> jboss-javax-sql-api_7.0_spec module jar does not contains javax/sql/rowset/rowset.properties.
> Fix should be trivial, moving the file in the project from src/main/java to src/main/resources will do the job.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 10:01:05 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 1 Sep 2015 10:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-941) The file
 javax/sql/rowset/rowset.properties is not present in
 jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
In-Reply-To: <JIRA.12583427.1441112500000@Atlassian.JIRA>
References: <JIRA.12583427.1441112500000@Atlassian.JIRA>
	<JIRA.12583427.1441112500000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583427.1441112500000.10879.1441116065403@Atlassian.JIRA>


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

Tomaz Cerar closed WFCORE-941.
------------------------------
    Fix Version/s: 2.0.0.Beta5
       Resolution: Out of Date


2.0.0.Final also has fix which was wildfly core already uses.

> The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-941
>                 URL: https://issues.jboss.org/browse/WFCORE-941
>             Project: WildFly Core
>          Issue Type: Component  Upgrade
>    Affects Versions: 1.0.1.Final, 1.0.2.Final
>            Reporter: Marco Mondini
>             Fix For: 2.0.0.Beta5
>
>
> Changing version of the artifact "jboss-javax-sql-api_7.0_spec" to 1.1.1.Final will fix the issue.
> (see: https://issues.jboss.org/browse/WFLY-4884)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 10:47:06 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 1 Sep 2015 10:47:06 -0400 (EDT)
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.1441118790739@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583453.1441118790000.11068.1441118826006@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5253:
--------------------------------------

             Summary: [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)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Critical


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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 10:47:06 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 1 Sep 2015 10:47:06 -0400 (EDT)
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.11071.1441118826121@Atlassian.JIRA>


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

Radim Hatlapatka updated WFLY-5253:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> [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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 11:04:05 2015
From: issues at jboss.org (Marco Mondini (JIRA))
Date: Tue, 1 Sep 2015 11:04:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-941) The file
 javax/sql/rowset/rowset.properties is not present in
 jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
In-Reply-To: <JIRA.12583427.1441112500000@Atlassian.JIRA>
References: <JIRA.12583427.1441112500000@Atlassian.JIRA>
	<JIRA.12583427.1441112500000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583427.1441112500000.11159.1441119845600@Atlassian.JIRA>


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

Marco Mondini commented on WFCORE-941:
--------------------------------------

That will never go in Wildfly 9.x. Will it?

> The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-941
>                 URL: https://issues.jboss.org/browse/WFCORE-941
>             Project: WildFly Core
>          Issue Type: Component  Upgrade
>    Affects Versions: 1.0.1.Final, 1.0.2.Final
>            Reporter: Marco Mondini
>             Fix For: 2.0.0.Beta5
>
>
> Changing version of the artifact "jboss-javax-sql-api_7.0_spec" to 1.1.1.Final will fix the issue.
> (see: https://issues.jboss.org/browse/WFLY-4884)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 11:37:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Sep 2015 11:37:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1943) GossipRouter: use NioServer
 to re-implement
In-Reply-To: <JIRA.12578872.1437561354000@Atlassian.JIRA>
References: <JIRA.12578872.1437561354000@Atlassian.JIRA>
	<JIRA.12578872.1437561354000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578872.1437561354000.11307.1441121825442@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1943:
--------------------------------

Created classes TcpClient / NioClient, TcpServer / NioServer and re-implemented GossipRouter / RouterStub / RouterStubManager with them.

> GossipRouter: use NioServer to re-implement
> -------------------------------------------
>
>                 Key: JGRP-1943
>                 URL: https://issues.jboss.org/browse/JGRP-1943
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> If {{NioServer}} is used to implement {{GossipRouter}}, then we'd remove the need to use 1 thread per connection, but all requests would be handled by a configurable thread pool.
> Should also reduce the code size of {{GossipRouter}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 11:37:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Sep 2015 11:37:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1943) GossipRouter: use NioServer
 to re-implement
In-Reply-To: <JIRA.12578872.1437561354000@Atlassian.JIRA>
References: <JIRA.12578872.1437561354000@Atlassian.JIRA>
	<JIRA.12578872.1437561354000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578872.1437561354000.11314.1441121825706@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1943:
--------------------------------

- nio <true|false> can be used to determine whether GR is blocking or non-blocking

> GossipRouter: use NioServer to re-implement
> -------------------------------------------
>
>                 Key: JGRP-1943
>                 URL: https://issues.jboss.org/browse/JGRP-1943
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> If {{NioServer}} is used to implement {{GossipRouter}}, then we'd remove the need to use 1 thread per connection, but all requests would be handled by a configurable thread pool.
> Should also reduce the code size of {{GossipRouter}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 11:37:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Sep 2015 11:37:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1943) GossipRouter: use NioServer
 to re-implement
In-Reply-To: <JIRA.12578872.1437561354000@Atlassian.JIRA>
References: <JIRA.12578872.1437561354000@Atlassian.JIRA>
	<JIRA.12578872.1437561354000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578872.1437561354000.11310.1441121825509@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1943.
----------------------------
    Resolution: Done


> GossipRouter: use NioServer to re-implement
> -------------------------------------------
>
>                 Key: JGRP-1943
>                 URL: https://issues.jboss.org/browse/JGRP-1943
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> If {{NioServer}} is used to implement {{GossipRouter}}, then we'd remove the need to use 1 thread per connection, but all requests would be handled by a configurable thread pool.
> Should also reduce the code size of {{GossipRouter}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 11:43:05 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 1 Sep 2015 11:43:05 -0400 (EDT)
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.1441122181964@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583463.1441122181000.11316.1441122185250@Atlassian.JIRA>

Paul Ferraro created WFLY-5254:
----------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 11:51:05 2015
From: issues at jboss.org (Nick Sawadsky (JIRA))
Date: Tue, 1 Sep 2015 11:51:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.11353.1441122665254@Atlassian.JIRA>


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

Nick Sawadsky commented on JGRP-1954:
-------------------------------------

Yes, I think you're right, that should avoid the security risks I was concerned about (I thought the code would have to eval the JSON string that was returned). As long as JSON.parse is available, that seems like a good way to go. There are some posts about JSON.parse not being available when running on Java 6, but hopefully that is resolved in Java 7 and later.

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 11:54:05 2015
From: issues at jboss.org (Nick Sawadsky (JIRA))
Date: Tue, 1 Sep 2015 11:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.11365.1441122845475@Atlassian.JIRA>


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

Nick Sawadsky edited comment on JGRP-1954 at 9/1/15 11:53 AM:
--------------------------------------------------------------

Yes, I think you're right, that should avoid the security risks I was concerned about (I thought the code would have to eval the JSON string that was returned). 

There are some posts about JSON.parse not being available when running on Java 6, but hopefully that is resolved in Java 7 and later. [~belaban] do you think Java 6 compatibility is a requirement for the fix? If so, this approach may become a little more complicated, as a Javascript implementation of JSON.parse would have to be loaded in to the ScriptEngine instance. 


was (Author: nsawadsky):
Yes, I think you're right, that should avoid the security risks I was concerned about (I thought the code would have to eval the JSON string that was returned). As long as JSON.parse is available, that seems like a good way to go. There are some posts about JSON.parse not being available when running on Java 6, but hopefully that is resolved in Java 7 and later.

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 12:01:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Sep 2015 12:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.11395.1441123265345@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1954:
--------------------------------

Hi Nick,

Java 6 is absolutely *not* a requirement as 3.6.5 is already on Java 7 as base line.
If you think the cleaner approach is to move SWIFT_PING into its own separate project, that's a valid choice, too. But Thomas kind of seemed against it, or did I only imply this Thomas ?

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 12:05:05 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Sep 2015 12:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-818) Listeners declared in
 kmodule.xml are not registered in StatelessKieSession
In-Reply-To: <JIRA.12575016.1434386305000@Atlassian.JIRA>
References: <JIRA.12575016.1434386305000@Atlassian.JIRA>
	<JIRA.12575016.1434386305000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575016.1434386305000.11414.1441123505914@Atlassian.JIRA>


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

RH Bugzilla Integration commented on DROOLS-818:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1233197|https://bugzilla.redhat.com/show_bug.cgi?id=1233197] from ON_QA to VERIFIED

> Listeners declared in kmodule.xml are not registered in StatelessKieSession
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-818
>                 URL: https://issues.jboss.org/browse/DROOLS-818
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>
> Listener declared in kmodule.xml as in the following snippet of XML works on stateful KieSession, but are not registered on stateless ones.
> {code}
>     <ksession name="statelessKieSession1" type="stateless">
>       <listeners>
>         <ruleRuntimeEventListener type="com.esrx.ref.testproject.TestRuleRuntimeEventListener"/>
>       </listeners>
>     </ksession>
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 12:29:05 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 1 Sep 2015 12:29:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3248) Clustering Extended testsuite
	is broken
In-Reply-To: <JIRA.12537869.1397157166000@Atlassian.JIRA>
References: <JIRA.12537869.1397157166000@Atlassian.JIRA>
	<JIRA.12537869.1397157166000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12537869.1397157166000.11510.1441124945390@Atlassian.JIRA>


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

Radoslav Husar reassigned WFLY-3248:
------------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)


> Clustering Extended testsuite is broken
> ---------------------------------------
>
>                 Key: WFLY-3248
>                 URL: https://issues.jboss.org/browse/WFLY-3248
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 12:29:05 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 1 Sep 2015 12:29:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3248) Clustering Extended testsuite
	is broken
In-Reply-To: <JIRA.12537869.1397157166000@Atlassian.JIRA>
References: <JIRA.12537869.1397157166000@Atlassian.JIRA>
	<JIRA.12537869.1397157166000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12537869.1397157166000.11514.1441124945479@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-3248:
---------------------------------
    Fix Version/s:     (was: 10.0.0.CR1)


> Clustering Extended testsuite is broken
> ---------------------------------------
>
>                 Key: WFLY-3248
>                 URL: https://issues.jboss.org/browse/WFLY-3248
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 12:29:05 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 1 Sep 2015 12:29:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3248) Clustering Extended testsuite
	is broken
In-Reply-To: <JIRA.12537869.1397157166000@Atlassian.JIRA>
References: <JIRA.12537869.1397157166000@Atlassian.JIRA>
	<JIRA.12537869.1397157166000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12537869.1397157166000.11518.1441124945572@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-3248:
---------------------------------
    Priority: Minor  (was: Major)


> Clustering Extended testsuite is broken
> ---------------------------------------
>
>                 Key: WFLY-3248
>                 URL: https://issues.jboss.org/browse/WFLY-3248
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 12:48:05 2015
From: issues at jboss.org (Thomas Segismont (JIRA))
Date: Tue, 1 Sep 2015 12:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.11544.1441126085326@Atlassian.JIRA>


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

Thomas Segismont commented on JGRP-1954:
----------------------------------------

[~belaban] No I'm not against it.

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 13:14:05 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 1 Sep 2015 13:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1285) rar-info: CCI interface
 information missing
In-Reply-To: <JIRA.12579918.1438274031000@Atlassian.JIRA>
References: <JIRA.12579918.1438274031000@Atlassian.JIRA>
	<JIRA.12579918.1438274031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579918.1438274031000.11656.1441127645746@Atlassian.JIRA>


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

Jesper Pedersen updated JBJCA-1285:
-----------------------------------
    Fix Version/s: 1.2.7.Final
                       (was: 1.2.6.Final)


> rar-info: CCI interface information missing
> -------------------------------------------
>
>                 Key: JBJCA-1285
>                 URL: https://issues.jboss.org/browse/JBJCA-1285
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: AS
>            Reporter: Jesper Pedersen
>            Assignee: Johnathon Lee
>             Fix For: 1.2.7.Final
>
>
> If a resource adapter is using CCI then the ConnectionFactory and Connection information isn't included in the report.
> The information should be based directly on the actual interface classes



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 13:15:07 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 1 Sep 2015 13:15:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1269) rar-info: Exceptions during
	scan
In-Reply-To: <JIRA.12571446.1431437335000@Atlassian.JIRA>
References: <JIRA.12571446.1431437335000@Atlassian.JIRA>
	<JIRA.12571446.1431437335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571446.1431437335000.11660.1441127707762@Atlassian.JIRA>


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

Jesper Pedersen updated JBJCA-1269:
-----------------------------------
    Fix Version/s: 1.2.7.Final
                       (was: 1.2.6.Final)


> rar-info: Exceptions during scan
> --------------------------------
>
>                 Key: JBJCA-1269
>                 URL: https://issues.jboss.org/browse/JBJCA-1269
>             Project: IronJacamar
>          Issue Type: Task
>          Components: AS
>            Reporter: Jesper Pedersen
>            Assignee: Johnathon Lee
>             Fix For: 1.2.7.Final
>
>
> The rar-info tool may display exceptions during its scan for certain conditions
> {noformat}
> t.printStackTrace(System.err);
> {noformat}
> These stack traces should in addition be appended to a <rar-file>-exceptions.txt file for easier attachment



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 13:16:05 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 1 Sep 2015 13:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1291) IronJacamar 1.2.6.Final
In-Reply-To: <JIRA.12583474.1441127736000@Atlassian.JIRA>
References: <JIRA.12583474.1441127736000@Atlassian.JIRA>
	<JIRA.12583474.1441127736836@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583474.1441127736000.11677.1441127765525@Atlassian.JIRA>

Jesper Pedersen created JBJCA-1291:
--------------------------------------

             Summary: IronJacamar 1.2.6.Final
                 Key: JBJCA-1291
                 URL: https://issues.jboss.org/browse/JBJCA-1291
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.2.6.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12327680



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 13:55:05 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 1 Sep 2015 13:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1291) IronJacamar 1.2.6.Final
In-Reply-To: <JIRA.12583474.1441127736000@Atlassian.JIRA>
References: <JIRA.12583474.1441127736000@Atlassian.JIRA>
	<JIRA.12583474.1441127736000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583474.1441127736000.11791.1441130105274@Atlassian.JIRA>


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

Jesper Pedersen resolved JBJCA-1291.
------------------------------------
    Resolution: Done


> IronJacamar 1.2.6.Final
> -----------------------
>
>                 Key: JBJCA-1291
>                 URL: https://issues.jboss.org/browse/JBJCA-1291
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.2.6.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12327680



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 15:04:05 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 1 Sep 2015 15:04:05 -0400 (EDT)
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.1441134232417@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583483.1441134232000.12069.1441134245230@Atlassian.JIRA>

Kabir Khan created WFLY-5255:
--------------------------------

             Summary: 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 15:29:05 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 1 Sep 2015 15:29:05 -0400 (EDT)
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.12100.1441135745360@Atlassian.JIRA>


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

Rob Stryker reopened WFLY-5249:
-------------------------------


there are still users of wf9 who check out the 9.x branch of this repository to engage in quickstarts.  Shouldn't this be fixed in the 9.x branch at least, so that users who check out 9.x of quickstarts can import without error?

> 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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 16:47:05 2015
From: issues at jboss.org (Manuel Colchete (JIRA))
Date: Tue, 1 Sep 2015 16:47:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener
 request client certificate despite verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366080@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.12278.1441140425260@Atlassian.JIRA>

Manuel Colchete created WFLY-5256:
-------------------------------------

             Summary: HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED
                 Key: WFLY-5256
                 URL: https://issues.jboss.org/browse/WFLY-5256
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: Manuel Colchete
            Assignee: Stuart Douglas
            Priority: Minor
             Fix For: 8.0.0.Final


HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED)




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 16:48:05 2015
From: issues at jboss.org (Manuel Colchete (JIRA))
Date: Tue, 1 Sep 2015 16:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener
 request client certificate despite verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.12281.1441140485477@Atlassian.JIRA>


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

Manuel Colchete updated WFLY-5256:
----------------------------------
    Affects Version/s: 8.2.0.Final
                           (was: 8.0.0.CR1)


> HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5256
>                 URL: https://issues.jboss.org/browse/WFLY-5256
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Manuel Colchete
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 16:48:05 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 1 Sep 2015 16:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-942) Parameter completion for
 :read-resource and :read-children-resources is broken
In-Reply-To: <JIRA.12583491.1441140483000@Atlassian.JIRA>
References: <JIRA.12583491.1441140483000@Atlassian.JIRA>
	<JIRA.12583491.1441140483372@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583491.1441140483000.12289.1441140485700@Atlassian.JIRA>

Brian Stansberry created WFCORE-942:
---------------------------------------

             Summary: Parameter completion for :read-resource and :read-children-resources is broken
                 Key: WFCORE-942
                 URL: https://issues.jboss.org/browse/WFCORE-942
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 2.0.0.Beta5
            Reporter: Brian Stansberry
            Assignee: Alexey Loubyansky
            Priority: Critical
             Fix For: 2.0.0.CR1


When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 16:53:05 2015
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 1 Sep 2015 16:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-281) Investigate if it's possible to
 modify the OTP SASL mechanism and password implementation to make use of
 the credential verification API
In-Reply-To: <JIRA.12583493.1441140776000@Atlassian.JIRA>
References: <JIRA.12583493.1441140776000@Atlassian.JIRA>
	<JIRA.12583493.1441140776004@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583493.1441140776000.12307.1441140785190@Atlassian.JIRA>

Farah Juma created ELY-281:
------------------------------

             Summary: Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API
                 Key: ELY-281
                 URL: https://issues.jboss.org/browse/ELY-281
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: SASL
            Reporter: Farah Juma
            Assignee: Farah Juma


The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds.

Relevant chat discussion:

{quote}
\[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm
\[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update
\[8:43 AM\] Kabir Khan: That is what I had planned
\[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally
\[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible
\[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though
\[8:44 AM\] Kabir Khan: the first option is what stood out to me
\[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext
{quote}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 17:04:05 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 1 Sep 2015 17:04:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-943) Add missing remoting
 transformers for EAP 6.4.0 (ModelVersion 1.4.0)
In-Reply-To: <JIRA.12583494.1441141389000@Atlassian.JIRA>
References: <JIRA.12583494.1441141389000@Atlassian.JIRA>
	<JIRA.12583494.1441141389986@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583494.1441141389000.12328.1441141445248@Atlassian.JIRA>

Kabir Khan created WFCORE-943:
---------------------------------

             Summary: Add missing remoting transformers for EAP 6.4.0 (ModelVersion 1.4.0)
                 Key: WFCORE-943
                 URL: https://issues.jboss.org/browse/WFCORE-943
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Domain Management
    Affects Versions: 2.0.0.Beta5
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 2.0.0.CR1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 17:09:05 2015
From: issues at jboss.org (Dennis Reed (JIRA))
Date: Tue, 1 Sep 2015 17:09:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is
 not connected" error during shutdown
In-Reply-To: <JIRA.12583496.1441141740000@Atlassian.JIRA>
References: <JIRA.12583496.1441141740000@Atlassian.JIRA>
	<JIRA.12583496.1441141740147@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583496.1441141740000.12339.1441141745301@Atlassian.JIRA>

Dennis Reed created JGRP-1958:
---------------------------------

             Summary: RequestCorrelator "channel is not connected" error during shutdown
                 Key: JGRP-1958
                 URL: https://issues.jboss.org/browse/JGRP-1958
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.12
            Reporter: Dennis Reed
            Assignee: Bela Ban
            Priority: Minor


Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply:

ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected
        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
        at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
        at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
        at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
        [incoming JGroups message]

It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message.
It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 17:29:05 2015
From: issues at jboss.org (Marcio Ricardo Hatzlhoffer Correia (JIRA))
Date: Tue, 1 Sep 2015 17:29:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5257) Unix Domain Socket Listener
	to Undertow
In-Reply-To: <JIRA.12583497.1441142941000@Atlassian.JIRA>
References: <JIRA.12583497.1441142941000@Atlassian.JIRA>
	<JIRA.12583497.1441142941654@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583497.1441142941000.12346.1441142945297@Atlassian.JIRA>

Marcio Ricardo Hatzlhoffer Correia created WFLY-5257:
--------------------------------------------------------

             Summary: Unix Domain Socket Listener to Undertow
                 Key: WFLY-5257
                 URL: https://issues.jboss.org/browse/WFLY-5257
             Project: WildFly
          Issue Type: Feature Request
          Components: IO
         Environment: Unix/Linux
            Reporter: Marcio Ricardo Hatzlhoffer Correia
            Assignee: Jason Greene


For many cases, it's used an application like Apache or Nginx as a Reverse Proxy in front of Wildfly. As there is no option to use Unix Domain Socket, these applications use the TCP stack to redirect the connection to the Wildfly (Undertow) and it incurs a slight performance overhead. 

In the case of a Reverse Proxy configuration where your upstream server is on the same machine, you can get better performance by skipping the TCP/Network stack and using Unix Domain Sockets. A Unix Domain Socket is communication mechanism to do inter-process messaging within the operating system kernel, using the file system as the name space.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 18:11:05 2015
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 1 Sep 2015 18:11:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-281) Investigate if it's possible to
 modify the OTP SASL mechanism and password implementation to make use of
 the credential verification API
In-Reply-To: <JIRA.12583493.1441140776000@Atlassian.JIRA>
References: <JIRA.12583493.1441140776000@Atlassian.JIRA>
	<JIRA.12583493.1441140776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583493.1441140776000.12355.1441145465188@Atlassian.JIRA>


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

Farah Juma commented on ELY-281:
--------------------------------

*OTP credential updates*

For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. Note that the OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though).

*How OTP credential updates are currently handled*

PR [#277|https://github.com/wildfly-security/wildfly-elytron/pull/277] adds handling for {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}, as shown below. This is used for both the OTP sequence reset case as well as the non-reset case.

https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L716-L720

*Using the credential verification API instead*

An alternative option is to pass the guess that's being verified to the realm and have the realm update the stored credential if verification succeeds. I've got an initial implementation of this approach here (see the three latest commits):

https://github.com/fjuma/wildfly-elytron/commits/ELY-281

However, there are a couple of issues with this approach:

1. The [OTP sequence reset case|https://github.com/fjuma/wildfly-elytron/blob/ELY-281/src/main/java/org/wildfly/security/sasl/otp/OTPSaslServer.java#L199-L202] still needs to be handled by {{ServerAuthenticationContext}} via {{CredentialUpdateCallback}}. This might be ok though since other mechanisms may also need to support password resets.

2. This approach relies on {{PasswordFactory#verify}} being called from {{ModifiableRealmIdentity#verifyCredential}}. Once PR [#271|https://github.com/wildfly-security/wildfly-elytron/pull/271] is merged, support for OTP passwords will also be available in the LDAP realm. However, {{LdapRealmIdentity#verifyCredential}} does not call {{PasswordFactory#verify}} so it's not clear yet how OTP credential verification and updates would be handled in cases like this with this approach.

> Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-281
>                 URL: https://issues.jboss.org/browse/ELY-281
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds.
> Relevant chat discussion:
> {quote}
> \[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm
> \[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update
> \[8:43 AM\] Kabir Khan: That is what I had planned
> \[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally
> \[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible
> \[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though
> \[8:44 AM\] Kabir Khan: the first option is what stood out to me
> \[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 18:17:05 2015
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 1 Sep 2015 18:17:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-281) Investigate if it's possible to
 modify the OTP SASL mechanism and password implementation to make use of
 the credential verification API
In-Reply-To: <JIRA.12583493.1441140776000@Atlassian.JIRA>
References: <JIRA.12583493.1441140776000@Atlassian.JIRA>
	<JIRA.12583493.1441140776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583493.1441140776000.12360.1441145825184@Atlassian.JIRA>


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

Farah Juma edited comment on ELY-281 at 9/1/15 6:16 PM:
--------------------------------------------------------

*OTP credential updates*

For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. Note that the OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though).

*How OTP credential updates are currently handled*

PR [#277|https://github.com/wildfly-security/wildfly-elytron/pull/277] adds handling for {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}, as shown below. This is used for both the OTP sequence reset case as well as the non-reset case.

https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L716-L720

*Using the credential verification API instead*

An alternative option is to pass the guess that's being verified to the realm and have the realm update the stored credential if verification succeeds. I've got an initial implementation of this approach here (see the three latest commits):

https://github.com/fjuma/wildfly-elytron/commits/ELY-281

However, there are a couple of issues with this approach:

1. The [OTP sequence reset case|https://github.com/fjuma/wildfly-elytron/blob/ELY-281/src/main/java/org/wildfly/security/sasl/otp/OTPSaslServer.java#L199-L202] still needs to be handled by {{ServerAuthenticationContext}} via {{CredentialUpdateCallback}}. This might be ok though since other mechanisms may also need to support password resets.

2. This approach relies on {{PasswordFactory#verify}} being called from {{ModifiableRealmIdentity#verifyCredential}}. Once PR [#271|https://github.com/wildfly-security/wildfly-elytron/pull/271] is merged, support for OTP passwords will also be available in the LDAP realm. However, {{LdapRealmIdentity#verifyCredential}} does not call {{PasswordFactory#verify}} so it's not clear how OTP credential verification and updates would be handled in cases like this with this approach.


was (Author: fjuma):
*OTP credential updates*

For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. Note that the OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though).

*How OTP credential updates are currently handled*

PR [#277|https://github.com/wildfly-security/wildfly-elytron/pull/277] adds handling for {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}, as shown below. This is used for both the OTP sequence reset case as well as the non-reset case.

https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L716-L720

*Using the credential verification API instead*

An alternative option is to pass the guess that's being verified to the realm and have the realm update the stored credential if verification succeeds. I've got an initial implementation of this approach here (see the three latest commits):

https://github.com/fjuma/wildfly-elytron/commits/ELY-281

However, there are a couple of issues with this approach:

1. The [OTP sequence reset case|https://github.com/fjuma/wildfly-elytron/blob/ELY-281/src/main/java/org/wildfly/security/sasl/otp/OTPSaslServer.java#L199-L202] still needs to be handled by {{ServerAuthenticationContext}} via {{CredentialUpdateCallback}}. This might be ok though since other mechanisms may also need to support password resets.

2. This approach relies on {{PasswordFactory#verify}} being called from {{ModifiableRealmIdentity#verifyCredential}}. Once PR [#271|https://github.com/wildfly-security/wildfly-elytron/pull/271] is merged, support for OTP passwords will also be available in the LDAP realm. However, {{LdapRealmIdentity#verifyCredential}} does not call {{PasswordFactory#verify}} so it's not clear yet how OTP credential verification and updates would be handled in cases like this with this approach.

> Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-281
>                 URL: https://issues.jboss.org/browse/ELY-281
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds.
> Relevant chat discussion:
> {quote}
> \[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm
> \[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update
> \[8:43 AM\] Kabir Khan: That is what I had planned
> \[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally
> \[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible
> \[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though
> \[8:44 AM\] Kabir Khan: the first option is what stood out to me
> \[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 18:39:05 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 1 Sep 2015 18:39:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-942) Parameter completion for
 :read-resource and :read-children-resources is broken
In-Reply-To: <JIRA.12583491.1441140483000@Atlassian.JIRA>
References: <JIRA.12583491.1441140483000@Atlassian.JIRA>
	<JIRA.12583491.1441140483000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583491.1441140483000.12379.1441147145228@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-942:
-----------------------------------------

Seems there are other issues. From HipChat:

[5:02 PM] James R Perkins: Hmm... ...table-complete seems broken in CLI.
[5:29 PM] Scott Marlow: hmm, worked for me yesterday @jperkins
[5:30 PM] James R Perkins: I'm guessing it's recent. It somewhat works, but doing something like an :add(<TAB> just closes the parenthesis rather than showing parameters.
[5:31 PM] Scott Marlow: ahh, I was just hitting tab in /subsystem
[5:31 PM] James R Perkins: Yeah that part works. It might only be attribute names.

		5:32 PM
		James R Perkins didn't look for any recent changes
[5:34 PM] Scott Marlow: @jperkins I'm seeing the same now, entered ":read-resource-description(" and pressed tab, it just closes the parenthesis
[5:35 PM] James R Perkins: Now I actually have to remember attribute names :)

> Parameter completion for :read-resource and :read-children-resources is broken
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-942
>                 URL: https://issues.jboss.org/browse/WFCORE-942
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 19:34:05 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 1 Sep 2015 19:34:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4515) Fix clustering transformers
 and reenable in mixed-domain tests
In-Reply-To: <JIRA.12568394.1429024821000@Atlassian.JIRA>
References: <JIRA.12568394.1429024821000@Atlassian.JIRA>
	<JIRA.12568394.1429024821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568394.1429024821000.12405.1441150445420@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-4515:
--------------------------------------

New problem:

java.lang.AssertionError: [("cache-container" => "*"),("distributed-cache" => "*"),("mixed-keyed-jdbc-store" => "MIXED_KEYED_JDBC_STORE")] Element 'dialect' is not known in target definition

> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
>                 Key: WFLY-4515
>                 URL: https://issues.jboss.org/browse/WFLY-4515
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Kabir Khan
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. 
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> 	mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
>    ("profile" => "full-ha"),
>    ("subsystem" => "infinispan"),
>    ("cache-container" => "server"),
>    ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> 	/subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ThreadsAttributesWriteHandler.java#L61 so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 19:36:05 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 1 Sep 2015 19:36:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4515) Fix clustering transformers
 and reenable in mixed-domain tests
In-Reply-To: <JIRA.12568394.1429024821000@Atlassian.JIRA>
References: <JIRA.12568394.1429024821000@Atlassian.JIRA>
	<JIRA.12568394.1429024821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568394.1429024821000.12411.1441150565362@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-4515:
---------------------------------
    Comment: was deleted

(was: New problem:

java.lang.AssertionError: [("cache-container" => "*"),("distributed-cache" => "*"),("mixed-keyed-jdbc-store" => "MIXED_KEYED_JDBC_STORE")] Element 'dialect' is not known in target definition)


> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
>                 Key: WFLY-4515
>                 URL: https://issues.jboss.org/browse/WFLY-4515
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Kabir Khan
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. 
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> 	mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
>    ("profile" => "full-ha"),
>    ("subsystem" => "infinispan"),
>    ("cache-container" => "server"),
>    ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> 	/subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ThreadsAttributesWriteHandler.java#L61 so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 22:04:05 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 1 Sep 2015 22:04:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5220) Tests in
 testsuite/integration/basic runs more time when -Dtest maven argument is
 used
In-Reply-To: <JIRA.12582788.1440671514000@Atlassian.JIRA>
References: <JIRA.12582788.1440671514000@Atlassian.JIRA>
	<JIRA.12582788.1440671514000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582788.1440671514000.12514.1441159445254@Atlassian.JIRA>


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

Stuart Douglas commented on WFLY-5220:
--------------------------------------

I am reverting this PR because it breaks -Dtest= usage

> Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5220
>                 URL: https://issues.jboss.org/browse/WFLY-5220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Multiple maven-surefire-plugin executions are started when {{-Dtest}} maven switch is used in {{testsuite/integration/basic}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue Sep  1 23:56:05 2015
From: issues at jboss.org (Andreas Redmer (JIRA))
Date: Tue, 1 Sep 2015 23:56:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5258) Unexpected behavior of
 negative priorities in container filters
In-Reply-To: <JIRA.12583505.1441166124000@Atlassian.JIRA>
References: <JIRA.12583505.1441166124000@Atlassian.JIRA>
	<JIRA.12583505.1441166124112@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583505.1441166124000.12542.1441166165254@Atlassian.JIRA>

Andreas Redmer created WFLY-5258:
------------------------------------

             Summary: Unexpected behavior of negative priorities in container filters
                 Key: WFLY-5258
                 URL: https://issues.jboss.org/browse/WFLY-5258
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 9.0.1.Final
         Environment: Windows/Linux
            Reporter: Andreas Redmer
            Assignee: Stuart Douglas
            Priority: Minor


Annotation a class that implements ContainerRequestFilter with @Priority(Integer.MIN_VALUE) works as expected. The filter is executed first. For ContainerResponseFilter it is executed in random order.

Priority values should generally be non-negative, with negative values reserved for special meanings such as "undefined" or "not specified". A specification that defines use of the Priority annotation may define the range of allowed priorities and any priority values with special meaning.

In this case the behaviour for negative Priorities is inconsistent between the 2 container filters. The correct way to work around this is to annotate:

@Priority(0)

Even though: many internet tutorials suggest:

@Priority(Integer.MIN_VALUE)

The implemntation oif logging filter in Glassfish does that too: https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/filter/LoggingFilter.java




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:08:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 02:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is
 not connected" error during shutdown
In-Reply-To: <JIRA.12583496.1441141740000@Atlassian.JIRA>
References: <JIRA.12583496.1441141740000@Atlassian.JIRA>
	<JIRA.12583496.1441141740000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583496.1441141740000.12752.1441174085544@Atlassian.JIRA>


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

Bela Ban updated JGRP-1958:
---------------------------
    Fix Version/s: 3.6.5


> RequestCorrelator "channel is not connected" error during shutdown
> ------------------------------------------------------------------
>
>                 Key: JGRP-1958
>                 URL: https://issues.jboss.org/browse/JGRP-1958
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>            Reporter: Dennis Reed
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply:
> ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         [incoming JGroups message]
> It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message.
> It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:12:05 2015
From: issues at jboss.org (Arto Huusko (JIRA))
Date: Wed, 2 Sep 2015 02:12:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5259) truststore path is ignored if
 provider is not JKS
In-Reply-To: <JIRA.12583510.1441174324000@Atlassian.JIRA>
References: <JIRA.12583510.1441174324000@Atlassian.JIRA>
	<JIRA.12583510.1441174324407@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583510.1441174324000.12763.1441174325339@Atlassian.JIRA>

Arto Huusko created WFLY-5259:
---------------------------------

             Summary: truststore path is ignored if provider is not JKS
                 Key: WFLY-5259
                 URL: https://issues.jboss.org/browse/WFLY-5259
             Project: WildFly
          Issue Type: Feature Request
          Components: ConfigAdmin, Security
    Affects Versions: 9.0.1.Final
            Reporter: Arto Huusko
            Assignee: Thomas Diesler


truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.

This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.

We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.

Even standard java supports PKCS12 truststores, where the same problem would occur.

So I would suggest that
 - if provider is JKS, path is mandatory
 - if provider is not JKS, but path is specified, it is passed to the provider



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:25:05 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 2 Sep 2015 02:25:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5220) Tests in
 testsuite/integration/basic runs more time when -Dtest maven argument is
 used
In-Reply-To: <JIRA.12582788.1440671514000@Atlassian.JIRA>
References: <JIRA.12582788.1440671514000@Atlassian.JIRA>
	<JIRA.12582788.1440671514000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582788.1440671514000.12777.1441175105281@Atlassian.JIRA>


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

Josef Cacek commented on WFLY-5220:
-----------------------------------

Stuart, how it breaks the usage? 
The correct is only one active surefire exeuction (with {{standalone-full.xml}} profile}}) when the {{-Dtest}} is used - as it's described in the profile comment.

{code:xml}
 <!-- When -Dtest=... is set, only the default surefire execution with standalone-full.xml will run. -->
{code}

It worked as described in the past, but stopped to work after this change:
https://github.com/wildfly/wildfly/commit/005567fe438049426292e4ca270060eadd8c9b7b#diff-ec12efbf5a13385ba26a3162a8b61e72R390

> Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5220
>                 URL: https://issues.jboss.org/browse/WFLY-5220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Multiple maven-surefire-plugin executions are started when {{-Dtest}} maven switch is used in {{testsuite/integration/basic}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:25:05 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 2 Sep 2015 02:25:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5220) Tests in
 testsuite/integration/basic runs more time when -Dtest maven argument is
 used
In-Reply-To: <JIRA.12582788.1440671514000@Atlassian.JIRA>
References: <JIRA.12582788.1440671514000@Atlassian.JIRA>
	<JIRA.12582788.1440671514000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582788.1440671514000.12780.1441175105358@Atlassian.JIRA>


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

Josef Cacek edited comment on WFLY-5220 at 9/2/15 2:24 AM:
-----------------------------------------------------------

Stuart, how it breaks the usage? 
The correct is only one active surefire exeuction (with {{standalone-full.xml}} profile) when the {{-Dtest}} is used - as it's described in the profile comment.

{code:xml}
 <!-- When -Dtest=... is set, only the default surefire execution with standalone-full.xml will run. -->
{code}

It worked as described in the past, but stopped to work after this change:
https://github.com/wildfly/wildfly/commit/005567fe438049426292e4ca270060eadd8c9b7b#diff-ec12efbf5a13385ba26a3162a8b61e72R390


was (Author: jcacek):
Stuart, how it breaks the usage? 
The correct is only one active surefire exeuction (with {{standalone-full.xml}} profile}}) when the {{-Dtest}} is used - as it's described in the profile comment.

{code:xml}
 <!-- When -Dtest=... is set, only the default surefire execution with standalone-full.xml will run. -->
{code}

It worked as described in the past, but stopped to work after this change:
https://github.com/wildfly/wildfly/commit/005567fe438049426292e4ca270060eadd8c9b7b#diff-ec12efbf5a13385ba26a3162a8b61e72R390

> Tests in testsuite/integration/basic runs more time when -Dtest maven argument is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5220
>                 URL: https://issues.jboss.org/browse/WFLY-5220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Multiple maven-surefire-plugin executions are started when {{-Dtest}} maven switch is used in {{testsuite/integration/basic}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:43:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 02:43:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.12812.1441176185357@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1956:
--------------------------------

Can you try with the following attributes enabled: ?
* {{remove_old_coords_on_view_change}}
* {{remove_all_files_on_view_change}}

The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store.
Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache.

> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:45:06 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 02:45:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.12823.1441176306097@Atlassian.JIRA>


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

Bela Ban edited comment on JGRP-1956 at 9/2/15 2:44 AM:
--------------------------------------------------------

Can you try with the following attributes enabled: ?
* {{remove_old_coords_on_view_change}}
* {{remove_all_files_on_view_change}}

The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store.
Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache.
Take a look at https://issues.jboss.org/browse/JGRP-1917 for details


was (Author: belaban):
Can you try with the following attributes enabled: ?
* {{remove_old_coords_on_view_change}}
* {{remove_all_files_on_view_change}}

The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store.
Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache.

> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:48:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 02:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.12827.1441176485295@Atlassian.JIRA>


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

Bela Ban edited comment on JGRP-1956 at 9/2/15 2:47 AM:
--------------------------------------------------------

Can you try with the following attributes enabled: ?
* {{remove_old_coords_on_view_change}}
* {{remove_all_files_on_view_change}}

The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store.
Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache.
Take a look at https://issues.jboss.org/browse/JGRP-1917 for details.
Doc: http://www.jgroups.org/manual/index.html#FILE_PING (removal of zombie files)


was (Author: belaban):
Can you try with the following attributes enabled: ?
* {{remove_old_coords_on_view_change}}
* {{remove_all_files_on_view_change}}

The reason old members are not immediately removed is that these members could have been split away, in a network partition, rather than crashed. If we want a merge to succeed in such a case, it is better to leave information about them in the store.
Note that {{TP.logical_addr_cache_max_size}} and {{TP.logical_addr_cache_expiration}} govern when stale entries will be removed. By default, you won't have more than 2000 stale elements in the cache.
Take a look at https://issues.jboss.org/browse/JGRP-1917 for details

> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 02:51:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 02:51:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.12839.1441176665399@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1956.
----------------------------
    Resolution: Won't Fix


I'm closing this as the instructions in my last comment should fix this issue. If this is not the case, please re-open.

> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 03:35:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 03:35:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.12908.1441179305430@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1957:
--------------------------------

This is similar to https://issues.jboss.org/browse/JGRP-1956: nodes cannot be removed from the {{x.list}} file because they might not have crashed, but were separated away by a network partition.
If you enable the 2 attributes I listed in JGRP-1956 and reduce the size and expiration time of the logical address cache, the old members will get removed. Just tested this locally.
Can you close the issue if this works for you ? Otherwise, contact me on IRC, as I want to release a 3.6.5 before before the end of the week. Otherwise, this issue gets pushed into 3.6.6.

> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 04:06:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 04:06:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is
 not connected" error during shutdown
In-Reply-To: <JIRA.12583496.1441141740000@Atlassian.JIRA>
References: <JIRA.12583496.1441141740000@Atlassian.JIRA>
	<JIRA.12583496.1441141740000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583496.1441141740000.12976.1441181165282@Atlassian.JIRA>


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

Bela Ban updated JGRP-1958:
---------------------------

Fixed in {{UNICAST2}} on master by removing the stack trace in the WARN log message. If a backport is needed, please cherry-pick the changes yourself.

> RequestCorrelator "channel is not connected" error during shutdown
> ------------------------------------------------------------------
>
>                 Key: JGRP-1958
>                 URL: https://issues.jboss.org/browse/JGRP-1958
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>            Reporter: Dennis Reed
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply:
> ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         [incoming JGroups message]
> It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message.
> It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 04:07:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 04:07:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is
 not connected" error during shutdown
In-Reply-To: <JIRA.12583496.1441141740000@Atlassian.JIRA>
References: <JIRA.12583496.1441141740000@Atlassian.JIRA>
	<JIRA.12583496.1441141740000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583496.1441141740000.12981.1441181225379@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1958.
----------------------------
    Resolution: Done


> RequestCorrelator "channel is not connected" error during shutdown
> ------------------------------------------------------------------
>
>                 Key: JGRP-1958
>                 URL: https://issues.jboss.org/browse/JGRP-1958
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>            Reporter: Dennis Reed
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply:
> ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
>         [incoming JGroups message]
> It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message.
> It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 04:36:05 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 2 Sep 2015 04:36:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-900)
 java.lang.IncompatibleClassChangeError error while using HashSets
In-Reply-To: <JIRA.12583366.1441087631000@Atlassian.JIRA>
References: <JIRA.12583366.1441087631000@Atlassian.JIRA>
	<JIRA.12583366.1441087631000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583366.1441087631000.13099.1441182965426@Atlassian.JIRA>


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

Mario Fusco resolved DROOLS-900.
--------------------------------
    Fix Version/s: 6.3.0.Final
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/a2ab9d4b9

One minor performance suggestion: if I'm understanding correctly you're creating exactly the same constant sets of values again and again at each constraint evaluation. Consider to refactor this sets as static and final public fields of a Java class and refer to this fields in your constraints.

> java.lang.IncompatibleClassChangeError error while using HashSets
> -----------------------------------------------------------------
>
>                 Key: DROOLS-900
>                 URL: https://issues.jboss.org/browse/DROOLS-900
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Pravasis Pattnaik
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 6.3.0.Final
>
>         Attachments: compiled-drl.txt, req.txt
>
>
> In the compiled drl file we were using (Sets.newHashSet(e1,e2,..)).contains(input) then we get an exception java.lang.IncompatibleClassChangeError: Class XYZ does not implement the requested interface java.util.Collection on large input sets.Here XYZ is our input ruleRequest to be evaluated. If I change it to Sets.newHashSet(e1,e2,..).contains(input) it fixes everything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 04:39:05 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 2 Sep 2015 04:39:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5235) CDI interceptors are not
 called when invoking observer method
In-Reply-To: <JIRA.12583196.1440938405000@Atlassian.JIRA>
References: <JIRA.12583196.1440938405000@Atlassian.JIRA>
	<JIRA.12583196.1440938405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583196.1440938405000.13105.1441183145295@Atlassian.JIRA>


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

Martin Kouba commented on WFLY-5235:
------------------------------------

I did a quick test (using {{TransactionSynchronizationRegistry}}) and it seems the interceptor is called and transaction is active. Therefore, we really need some more information. I wonder whether this could be a timing issue - for a web application the event is fired during {{ServletContextListener.contextInitialized()}} delivery and some services might not be available/fully initialized at this time (e.g. JPA).

> CDI interceptors are not called when invoking observer method
> -------------------------------------------------------------
>
>                 Key: WFLY-5235
>                 URL: https://issues.jboss.org/browse/WFLY-5235
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 9.0.1.Final
>            Reporter: Dirk Weil
>            Assignee: Martin Kouba
>
> The following code runs with an active transaction on WFLY 8.2.0, but failes with an TransactionRequiredException on WFLY 9.0.1:
> @ApplicationScoped
> public class InitCocktailDemoDataService
> {
>   @PersistenceContext
>   private EntityManager entityManager;
>   @Transactional
>   private void createDemoData(@Observes @Initialized(ApplicationScoped.class) Object event)
>   {
>         this.entityManager.merge(someEntity);
>       }
> It seems that interceptors aren't called at all - at least for observers of scope lifecycle events.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 04:46:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 04:46:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.13136.1441183565822@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1954:
--------------------------------

My preference is to leave {{SWIFT_PING}} in JGroups proper *if* we can come up with a solution that works and doesn't introduce new dependencies. Looks like Thomas suggested such a solution. The question is, will you Nick be able to adapt your suggested fix to take Thomas' solution into account ?
In any case, I'm moving this into 3.6.6. If we have a fix before the end of this week, we can still move it back to 3.6.5.

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 04:46:06 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 04:46:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.13146.1441183566105@Atlassian.JIRA>


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

Bela Ban updated JGRP-1954:
---------------------------
    Fix Version/s: 3.6.6
                       (was: 3.6.5)


> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:11:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 05:11:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.13216.1441185065516@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1957:
--------------------------------

Ah, I see what you mean now... Re-adding discovery info from {{FILE_PING}} to the logical address cache only happens for TCP, not for UDP.
I suggest reduce {{logical_addr_cache_expiration}} to be below {{MERGE3.max_interval}}.
There's also a method (exposed via JMX or probe) {{TCP.evictLogicalAddressCache(boolean force)}}: if {{force}} is set to true, all expired elements will be removed immediately.

> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:37:05 2015
From: issues at jboss.org (Sante Stanisci (JIRA))
Date: Wed, 2 Sep 2015 05:37:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-897) Binding variable or condition
In-Reply-To: <JIRA.12582821.1440680217000@Atlassian.JIRA>
References: <JIRA.12582821.1440680217000@Atlassian.JIRA>
	<JIRA.12582821.1440680217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582821.1440680217000.13318.1441186625247@Atlassian.JIRA>


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

Sante Stanisci commented on DROOLS-897:
---------------------------------------

Ok, give me an example to use in correctely mode this fix, since I have proposed several solutions during the discussion.

Best Regards

> Binding variable or condition
> -----------------------------
>
>                 Key: DROOLS-897
>                 URL: https://issues.jboss.org/browse/DROOLS-897
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.2.0.Final
>         Environment: Windows 8
>            Reporter: Sante Stanisci
>            Assignee: Mario Fusco
>              Labels: dynamic, instanciation, variable
>             Fix For: 6.3.0.Final
>
>         Attachments: rule.drl, workaround.drl
>
>
> In this example I have more classes that extends EntityBase (my class). In my intention, i would assign to variable $entity one of this class that is inserted in Ksession fact.
> I insert fact of CtbMovrCoan class
> In when statement of the rule at row 16, variable $entity is correctely, 
> but in then statement variable $entity becomes JtbRLavt class (first declared in then cond) and this behavior throw a ClassCastException, obviously.
> Can Help me?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:38:05 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 2 Sep 2015 05:38:05 -0400 (EDT)
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.1441186683617@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583538.1441186683000.13322.1441186685319@Atlassian.JIRA>

Tomas Remes created WFLY-5260:
---------------------------------

             Summary: 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: Stuart Douglas


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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:41:05 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 2 Sep 2015 05:41:05 -0400 (EDT)
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.13325.1441186865220@Atlassian.JIRA>


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

Tomas Remes commented on WFLY-5260:
-----------------------------------

Test is available at https://github.com/tremes/wildfly/tree/WFLY-5260-test.

> 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: Stuart Douglas
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:45:05 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 2 Sep 2015 05:45:05 -0400 (EDT)
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.13342.1441187105304@Atlassian.JIRA>


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

Martin Kouba reassigned WFLY-5260:
----------------------------------

    Assignee: Martin Kouba  (was: Stuart Douglas)


> 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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:48:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 05:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1959) TCPPING: initial_hosts are
 not read in the order in which they're listed
In-Reply-To: <JIRA.12583539.1441187255000@Atlassian.JIRA>
References: <JIRA.12583539.1441187255000@Atlassian.JIRA>
	<JIRA.12583539.1441187255353@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583539.1441187255000.13358.1441187285277@Atlassian.JIRA>

Bela Ban created JGRP-1959:
------------------------------

             Summary: TCPPING: initial_hosts are not read in the order in which they're listed
                 Key: JGRP-1959
                 URL: https://issues.jboss.org/browse/JGRP-1959
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.6.5


{{TCPPING}} doesn't contact the members listed in {{initial_hosts}} in the order in which they are defined. A user might list them in decreasing order of availability, so this is not optimal.
The reason is that we add {{initial_hosts}} and {{dynamic_hosts}} into a *hashset*, which causes reordering.
SOLUTION: use an ArrayList and add a presence check.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:57:05 2015
From: issues at jboss.org (=?UTF-8?Q?Jan_Bliz=C5=88=C3=A1k_=28JIRA=29?=)
Date: Wed, 2 Sep 2015 05:57:05 -0400 (EDT)
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.13389.1441187825433@Atlassian.JIRA>


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

Jan Bliz??k updated WFLY-5076:
------------------------------
    Fix Version/s: 10.0.0.CR1


> 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
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 05:57:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 05:57:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1959) TCPPING: initial_hosts are
 not read in the order in which they're listed
In-Reply-To: <JIRA.12583539.1441187255000@Atlassian.JIRA>
References: <JIRA.12583539.1441187255000@Atlassian.JIRA>
	<JIRA.12583539.1441187255000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583539.1441187255000.13392.1441187825519@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1959.
----------------------------
    Resolution: Done


> TCPPING: initial_hosts are not read in the order in which they're listed
> ------------------------------------------------------------------------
>
>                 Key: JGRP-1959
>                 URL: https://issues.jboss.org/browse/JGRP-1959
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> {{TCPPING}} doesn't contact the members listed in {{initial_hosts}} in the order in which they are defined. A user might list them in decreasing order of availability, so this is not optimal.
> The reason is that we add {{initial_hosts}} and {{dynamic_hosts}} into a *hashset*, which causes reordering.
> SOLUTION: use an ArrayList and add a presence check.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 05:57:05 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 2 Sep 2015 05:57:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-897) Binding variable or condition
In-Reply-To: <JIRA.12582821.1440680217000@Atlassian.JIRA>
References: <JIRA.12582821.1440680217000@Atlassian.JIRA>
	<JIRA.12582821.1440680217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582821.1440680217000.13395.1441187825604@Atlassian.JIRA>


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

Mario Fusco commented on DROOLS-897:
------------------------------------

I thought that we agreed that none of the solutions you suggested was doable and I tried to explain why.
The only solution that I see in your case is refactoring your domain model as I suggested above.


> Binding variable or condition
> -----------------------------
>
>                 Key: DROOLS-897
>                 URL: https://issues.jboss.org/browse/DROOLS-897
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.2.0.Final
>         Environment: Windows 8
>            Reporter: Sante Stanisci
>            Assignee: Mario Fusco
>              Labels: dynamic, instanciation, variable
>             Fix For: 6.3.0.Final
>
>         Attachments: rule.drl, workaround.drl
>
>
> In this example I have more classes that extends EntityBase (my class). In my intention, i would assign to variable $entity one of this class that is inserted in Ksession fact.
> I insert fact of CtbMovrCoan class
> In when statement of the rule at row 16, variable $entity is correctely, 
> but in then statement variable $entity becomes JtbRLavt class (first declared in then cond) and this behavior throw a ClassCastException, obviously.
> Can Help me?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:05:05 2015
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Wed, 2 Sep 2015 06:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5259) truststore path is ignored if
 provider is not JKS
In-Reply-To: <JIRA.12583510.1441174324000@Atlassian.JIRA>
References: <JIRA.12583510.1441174324000@Atlassian.JIRA>
	<JIRA.12583510.1441174324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583510.1441174324000.13402.1441188305336@Atlassian.JIRA>


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

Thomas Diesler updated WFLY-5259:
---------------------------------
    Component/s:     (was: ConfigAdmin)


> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
>                 Key: WFLY-5259
>                 URL: https://issues.jboss.org/browse/WFLY-5259
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 9.0.1.Final
>            Reporter: Arto Huusko
>            Assignee: Thomas Diesler
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
>  - if provider is JKS, path is mandatory
>  - if provider is not JKS, but path is specified, it is passed to the provider



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:05:05 2015
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Wed, 2 Sep 2015 06:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5259) truststore path is ignored if
 provider is not JKS
In-Reply-To: <JIRA.12583510.1441174324000@Atlassian.JIRA>
References: <JIRA.12583510.1441174324000@Atlassian.JIRA>
	<JIRA.12583510.1441174324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583510.1441174324000.13406.1441188305541@Atlassian.JIRA>


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

Thomas Diesler reassigned WFLY-5259:
------------------------------------

    Assignee: Darran Lofthouse  (was: Thomas Diesler)


> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
>                 Key: WFLY-5259
>                 URL: https://issues.jboss.org/browse/WFLY-5259
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 9.0.1.Final
>            Reporter: Arto Huusko
>            Assignee: Darran Lofthouse
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
>  - if provider is JKS, path is mandatory
>  - if provider is not JKS, but path is specified, it is passed to the provider



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:09:05 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Sep 2015 06:09:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-944) truststore path is ignored
 if provider is not JKS
In-Reply-To: <JIRA.12583510.1441174324000@Atlassian.JIRA>
References: <JIRA.12583510.1441174324000@Atlassian.JIRA>
	<JIRA.12583510.1441174324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583510.1441174324000.13413.1441188545377@Atlassian.JIRA>


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

Darran Lofthouse moved WFLY-5259 to WFCORE-944:
-----------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-944  (was: WFLY-5259)
          Component/s: Security
                           (was: Security)
    Affects Version/s:     (was: 9.0.1.Final)


> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
>                 Key: WFCORE-944
>                 URL: https://issues.jboss.org/browse/WFCORE-944
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Arto Huusko
>            Assignee: Darran Lofthouse
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
>  - if provider is JKS, path is mandatory
>  - if provider is not JKS, but path is specified, it is passed to the provider



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:15:06 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 2 Sep 2015 06:15:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.13423.1441188906042@Atlassian.JIRA>


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

Tom Jenkinson commented on WFLY-5020:
-------------------------------------

Hi Stefano, now that JBJCA-1291 is ready please can you raise the PR for this one from your branch?

> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:52:05 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 2 Sep 2015 06:52:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078032@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.13482.1441191125573@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5261:
--------------------------------------

             Summary: Can't reload server when JTS transactions are used
                 Key: WFLY-5261
                 URL: https://issues.jboss.org/browse/WFLY-5261
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
            Reporter: Ond?ej Chaloupka
            Assignee: Tom Jenkinson
            Priority: Critical


It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.

[1]
{code}
WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
 at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
 at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
 at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
 at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
 at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
 at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
 at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
 at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
 at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
 at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
 at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
 at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
 at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
 at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
 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)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 06:52:05 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 2 Sep 2015 06:52:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.13486.1441191125720@Atlassian.JIRA>


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

Ond?ej Chaloupka reassigned WFLY-5261:
--------------------------------------

    Assignee: Tomasz Adamski  (was: Tom Jenkinson)


> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 06:52:05 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 2 Sep 2015 06:52:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.13489.1441191125796@Atlassian.JIRA>


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

Ond?ej Chaloupka updated WFLY-5261:
-----------------------------------
    Component/s: IIOP


> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 06:53:05 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 2 Sep 2015 06:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.13494.1441191185366@Atlassian.JIRA>


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

Ond?ej Chaloupka updated WFLY-5261:
-----------------------------------
    Steps to Reproduce: Use attached {{standalone-full.jts.xml}} config file. Start server and connect with {{jboss-cli.sh -c}} and run {{:reload}} operation.


> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 06:54:05 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 2 Sep 2015 06:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.13499.1441191245269@Atlassian.JIRA>


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

Ond?ej Chaloupka updated WFLY-5261:
-----------------------------------
    Attachment: server.log
                standalone-full.jts.xml


> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 06:55:05 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 2 Sep 2015 06:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5262) Upgrade Arquillian to
	1.1.9.Final
In-Reply-To: <JIRA.12583547.1441191296000@Atlassian.JIRA>
References: <JIRA.12583547.1441191296000@Atlassian.JIRA>
	<JIRA.12583547.1441191296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583547.1441191296000.13506.1441191305462@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-5262:
---------------------------------
    Affects Version/s: 10.0.0.Beta2


> Upgrade Arquillian to 1.1.9.Final
> ---------------------------------
>
>                 Key: WFLY-5262
>                 URL: https://issues.jboss.org/browse/WFLY-5262
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Picks up a fix for ARQ-1976



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:55:05 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 2 Sep 2015 06:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5262) Upgrade Arquillian to
	1.1.9.Final
In-Reply-To: <JIRA.12583547.1441191296000@Atlassian.JIRA>
References: <JIRA.12583547.1441191296000@Atlassian.JIRA>
	<JIRA.12583547.1441191296664@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583547.1441191296000.13503.1441191305361@Atlassian.JIRA>

Radoslav Husar created WFLY-5262:
------------------------------------

             Summary: Upgrade Arquillian to 1.1.9.Final
                 Key: WFLY-5262
                 URL: https://issues.jboss.org/browse/WFLY-5262
             Project: WildFly
          Issue Type: Feature Request
          Components: Test Suite
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


Picks up a fix for ARQ-1976



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:56:05 2015
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 2 Sep 2015 06:56:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-888) Revert changes made in
	SECURITY-868
In-Reply-To: <JIRA.12572261.1432134072000@Atlassian.JIRA>
References: <JIRA.12572261.1432134072000@Atlassian.JIRA>
	<JIRA.12572261.1432134072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572261.1432134072000.13513.1441191365644@Atlassian.JIRA>


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

Ivo Studensky reopened SECURITY-888:
------------------------------------


Re-opening for the eap-6.4.x branch.

> Revert changes made in SECURITY-868
> -----------------------------------
>
>                 Key: SECURITY-888
>                 URL: https://issues.jboss.org/browse/SECURITY-888
>             Project: PicketBox 
>          Issue Type: Task
>    Affects Versions: PicketBox_4_9_1.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_9_2.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 06:56:05 2015
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 2 Sep 2015 06:56:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-888) Revert changes made in
	SECURITY-868
In-Reply-To: <JIRA.12572261.1432134072000@Atlassian.JIRA>
References: <JIRA.12572261.1432134072000@Atlassian.JIRA>
	<JIRA.12572261.1432134072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572261.1432134072000.13519.1441191365810@Atlassian.JIRA>


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

Ivo Studensky updated SECURITY-888:
-----------------------------------
    Git Pull Request: https://github.com/jbossas/redhat-picketbox/pull/7


> Revert changes made in SECURITY-868
> -----------------------------------
>
>                 Key: SECURITY-888
>                 URL: https://issues.jboss.org/browse/SECURITY-888
>             Project: PicketBox 
>          Issue Type: Task
>    Affects Versions: PicketBox_4_9_1.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_9_2.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 07:50:05 2015
From: issues at jboss.org (Karsten Ohme (JIRA))
Date: Wed, 2 Sep 2015 07:50:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.13673.1441194605346@Atlassian.JIRA>


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

Karsten Ohme commented on JGRP-1956:
------------------------------------

Are the options

* remove_old_coords_on_view_change
* remove_all_files_on_view_change

save, so that e.g. if a server crashes and restart only its own old files are removed?


> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 07:50:05 2015
From: issues at jboss.org (Karsten Ohme (JIRA))
Date: Wed, 2 Sep 2015 07:50:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.13676.1441194605419@Atlassian.JIRA>


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

Karsten Ohme edited comment on JGRP-1956 at 9/2/15 7:49 AM:
------------------------------------------------------------

Are the options

* remove_old_coords_on_view_change
* remove_all_files_on_view_change

save, so that e.g. if a server crashes and restarts only its own old files are removed?



was (Author: k_o_):
Are the options

* remove_old_coords_on_view_change
* remove_all_files_on_view_change

save, so that e.g. if a server crashes and restart only its own old files are removed?


> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 07:55:05 2015
From: issues at jboss.org (Manuel Colchete (JIRA))
Date: Wed, 2 Sep 2015 07:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener
 request client certificate despite verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.13690.1441194905501@Atlassian.JIRA>


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

Manuel Colchete updated WFLY-5256:
----------------------------------
    Fix Version/s:     (was: 8.0.0.Final)


> HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5256
>                 URL: https://issues.jboss.org/browse/WFLY-5256
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Manuel Colchete
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 07:56:05 2015
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 2 Sep 2015 07:56:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-891) rolesSearch is doing a
 needless LDAP call for each individual role
In-Reply-To: <JIRA.12572383.1432214616000@Atlassian.JIRA>
References: <JIRA.12572383.1432214616000@Atlassian.JIRA>
	<JIRA.12572383.1432214616000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572383.1432214616000.13698.1441194965539@Atlassian.JIRA>


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

Ivo Studensky resolved SECURITY-891.
------------------------------------
    Resolution: Done


Merged upstream.

> rolesSearch is doing a needless LDAP call for each individual role
> ------------------------------------------------------------------
>
>                 Key: SECURITY-891
>                 URL: https://issues.jboss.org/browse/SECURITY-891
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>    Affects Versions: PicketBox_4_9_2.Final
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/auth/spi/LdapExtLoginModule.java
> line 690:
>                // Query the context for the roleDN values
>                String[] attrNames = {roleAttributeID};
>                Attributes result = null;
>                if (sr.isRelative()) {
>                   result = ldapCtx.getAttributes(quoteDN(dn), attrNames);
> The getAttributes method forces another roundtrip to the LDAP server, while the required attribute is in fact already present on the "sr" SearchResult object.
> If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 08:04:06 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Wed, 2 Sep 2015 08:04:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-945) Cannot start embedded host
 controller in non-modular classloading environment
In-Reply-To: <JIRA.12583562.1441195388000@Atlassian.JIRA>
References: <JIRA.12583562.1441195388000@Atlassian.JIRA>
	<JIRA.12583562.1441195388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583562.1441195388000.13724.1441195446157@Atlassian.JIRA>


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

Petr Kremensky moved JBEAP-977 to WFCORE-945:
---------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-945  (was: JBEAP-977)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: CLI
                       Domain Management
                           (was: CLI)
                           (was: Domain Management)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.Beta4
                           (was: 7.0.0.DR9)


> Cannot start embedded host controller in non-modular classloading environment
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-945
>                 URL: https://issues.jboss.org/browse/WFCORE-945
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>
> Trying to start embedded host controller inside CLI running i in non-modular classloading environment gives me NPE.
> {noformat}
> $ unzip -q jboss-eap-7.0.0.DR9.zip 
> $ cd jboss-eap-7.0/bin/client/
> $ pwd
> /home/hudson/users-tmp/pkremens/jboss-eap-7.0/bin/client
> $ java -jar jboss-cli-client.jar 
> WARN: can't find jboss-cli.xml. Using default configuration values.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
> [standalone at embedded /] stop-embedded-server 
> [disconnected /] embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Failed to handle 'embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0': java.lang.NullPointerException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 08:16:08 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 2 Sep 2015 08:16:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-947) Constructor injection on EJB
 interceptors not working
In-Reply-To: <JIRA.12471260.1343332457000@Atlassian.JIRA>
References: <JIRA.12471260.1343332457000@Atlassian.JIRA>
	<JIRA.12471260.1343332457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471260.1343332457000.13804.1441196168552@Atlassian.JIRA>


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

Jozef Hartinger reassigned WFLY-947:
------------------------------------

    Assignee:     (was: Jozef Hartinger)


> Constructor injection on EJB interceptors not working
> -----------------------------------------------------
>
>                 Key: WFLY-947
>                 URL: https://issues.jboss.org/browse/WFLY-947
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Patrick Ruckstuhl
>
> Using JBoss 7.1 I use an EJB intercepter and would like to use constructor inject. This does not seem to work, but normal injection works fine.
> This one fails with
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011056: No default constructor for interceptor class
> public class CacheInterceptor {
>     private final DummyCache myCache;
>     @Inject
>     public CacheInterceptor(final DummyCache myCache) {
>         this.myCache = myCache;
>     }
>     @AroundInvoke
>     public Object intercept(final InvocationContext ctx) throws Exception {
> ....
>     }
> }
> but this works fine and DummyCache gets injected
> public class CacheInterceptor {
>     @Inject
>     private DummyCache myCache;
>     public CacheInterceptor() {
>     }
>     @AroundInvoke
>     public Object intercept(final InvocationContext ctx) throws Exception {
> ....
>     }
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 08:16:09 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 2 Sep 2015 08:16:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4966) Make sure Weld work fine
 outside the full feature pack
In-Reply-To: <JIRA.12578599.1437399937000@Atlassian.JIRA>
References: <JIRA.12578599.1437399937000@Atlassian.JIRA>
	<JIRA.12578599.1437399937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578599.1437399937000.13852.1441196169814@Atlassian.JIRA>


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

Jozef Hartinger reassigned WFLY-4966:
-------------------------------------

    Assignee:     (was: Jozef Hartinger)


> Make sure Weld work fine outside the full feature pack
> ------------------------------------------------------
>
>                 Key: WFLY-4966
>                 URL: https://issues.jboss.org/browse/WFLY-4966
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>             Fix For: 10.0.0.CR1
>
>
> Review subsystem's dependencies and make them optional if appropriate. 
> http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004202.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 08:16:10 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 2 Sep 2015 08:16:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2450) JSF managed classes do not
 support CDI interception
In-Reply-To: <JIRA.12518163.1383753817000@Atlassian.JIRA>
References: <JIRA.12518163.1383753817000@Atlassian.JIRA>
	<JIRA.12518163.1383753817000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518163.1383753817000.13864.1441196170112@Atlassian.JIRA>


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

Jozef Hartinger reassigned WFLY-2450:
-------------------------------------

    Assignee:     (was: Jozef Hartinger)


> JSF managed classes do not support CDI interception
> ---------------------------------------------------
>
>                 Key: WFLY-2450
>                 URL: https://issues.jboss.org/browse/WFLY-2450
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>            Reporter: Jozef Hartinger
>
> Testcase:
> https://github.com/mkouba/wildfly/commit/a9698d163da159dcbbf27da0679cf35c1ba0be87



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 08:19:05 2015
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Wed, 2 Sep 2015 08:19:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5171) Some tests can not deploy
 deployment with security manager
In-Reply-To: <JIRA.12582208.1440171264000@Atlassian.JIRA>
References: <JIRA.12582208.1440171264000@Atlassian.JIRA>
	<JIRA.12582208.1440171264000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582208.1440171264000.13888.1441196345680@Atlassian.JIRA>


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

Ondrej Kotek reassigned WFLY-5171:
----------------------------------

    Assignee: Ondrej Kotek  (was: Josef Cacek)


> Some tests can not deploy deployment with security manager
> ----------------------------------------------------------
>
>                 Key: WFLY-5171
>                 URL: https://issues.jboss.org/browse/WFLY-5171
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Ondrej Kotek
>
> *Description of problem:*
> Some tests are unable to deploy deployment with security manager with:
> {noformat}WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"accessDeclaredMembers\")\" in code source \"(vfs:/content/no-method-message-listener-test.ear/lib/common.jar <no signer certificates>)\" of \"null\")"}}{noformat}
> *Affected tests found so far:*
> * org.jboss.as.test.integration.ejb.mdb.messagelistener.nomethodinterface.NoMethodMessageListenerTestCase
> * org.jboss.as.test.integration.ejb.mdb.dynamic.DynamicMessageListenerTestCase
> * org.jboss.as.test.integration.management.cli.objectstore.TransactionObjectStoreTestCase
> * org.jboss.as.test.integration.naming.remote.multiple.MultipleClientRemoteJndiTestCase
> * org.jboss.as.test.integration.naming.remote.multiple.NestedRemoteContextTestCase
> * org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase
> *Steps to Reproduce NoMethodMessageListenerTestCase:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=NoMethodMessageListenerTestCase
> *Actual results:*
> {noformat}
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: no-method-message-listener-test.ear
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	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)
> 	at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
> 	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.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> 	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.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> 	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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> 	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.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	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.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> 	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.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	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.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	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.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	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:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.Exception: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"no-method-message-listener-test.ear\".\"message-driven-bean.jar\".component.SimpleMessageDrivenBean.START" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"no-method-message-listener-test.ear\".\"message-driven-bean.jar\".component.SimpleMessageDrivenBean.START: java.lang.RuntimeException: javax.resource.ResourceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"accessDeclaredMembers\")\" in code source \"(vfs:/content/no-method-message-listener-test.ear/lib/common.jar <no signer certificates>)\" of \"null\")
>     Caused by: java.lang.RuntimeException: javax.resource.ResourceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"accessDeclaredMembers\")\" in code source \"(vfs:/content/no-method-message-listener-test.ear/lib/common.jar <no signer certificates>)\" of \"null\")
>     Caused by: javax.resource.ResourceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"accessDeclaredMembers\")\" in code source \"(vfs:/content/no-method-message-listener-test.ear/lib/common.jar <no signer certificates>)\" of \"null\")
>     Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"accessDeclaredMembers\")\" in code source \"(vfs:/content/no-method-message-listener-test.ear/lib/common.jar <no signer certificates>)\" of \"null\")"}}
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> 	at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
> 	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)
> 	at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
> 	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.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> 	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.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> 	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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> 	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.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 	at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
> 	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.client.ContainerEventController.execute(ContainerEventController.java:101)
> 	at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> 	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.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	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.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	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.beforeClass(EventTestRunnerAdaptor.java:87)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
> 	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:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 08:48:05 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 2 Sep 2015 08:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5160) SingletonDeployment*TestCase
	fail on RHEL7
In-Reply-To: <JIRA.12582123.1440154452000@Atlassian.JIRA>
References: <JIRA.12582123.1440154452000@Atlassian.JIRA>
	<JIRA.12582123.1440154452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582123.1440154452000.13940.1441198085256@Atlassian.JIRA>


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

Marek Kopeck? commented on WFLY-5160:
-------------------------------------

[~pferraro]: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-Testsuite/view/EAP7-AS-Testsuite-Reproducers/job/eap-7x-as-testsuite-test-int-singldep-wf/3/testReport/

> SingletonDeployment*TestCase fail on RHEL7
> ------------------------------------------
>
>                 Key: WFLY-5160
>                 URL: https://issues.jboss.org/browse/WFLY-5160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta2
>
>
> *Description of problem:*
> * Two tests fail with "expected:<405> but was:<200>" error
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentJBossAllTestCase(SYNC-tcp)#test
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentDescriptorTestCase(SYNC-tcp)#test
> *How reproducible:*
> * RHEL7
> * IBM JDK 8, Oracle JDK 8, Open JDK 8
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dtest=SingletonDeploymentJBossAllTestCase,SingletonDeploymentDescriptorTestCase -DfailIfNoTests=false -Dts.clustering
> *Actual results:*
> {noformat}
> java.lang.AssertionError: expected:<405> but was:<200>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.junit.Assert.assertEquals(Assert.java:542)
> 	at org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentTestCase.test(SingletonDeploymentTestCase.java:84)
> 	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.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$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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 	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.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.createTestContext(ContainerEventController.java:129)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor5.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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: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: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:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No failures in test case.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Wed Sep  2 08:51:05 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Sep 2015 08:51:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot
 find custom ldap socket factory
In-Reply-To: <JIRA.12529141.1389397970000@Atlassian.JIRA>
References: <JIRA.12529141.1389397970000@Atlassian.JIRA>
	<JIRA.12529141.1389397970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529141.1389397970000.13954.1441198265654@Atlassian.JIRA>


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

RH Bugzilla Integration commented on SECURITY-784:
--------------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1052644|https://bugzilla.redhat.com/show_bug.cgi?id=1052644] from ASSIGNED to POST

> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
>                 Key: SECURITY-784
>                 URL: https://issues.jboss.org/browse/SECURITY-784
>             Project: PicketBox 
>          Issue Type: Feature Request
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Pedro Igor
>         Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the  "java.naming.ldap.factory.socket" property in as an
> module-option:
>   <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
>      at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
>      at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
>      at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
>      at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk.  Unfortunately, that did not work.  I also added the socket
> factory jar to the jre/lib/ext directory.  That didn't work either.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 08:54:05 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 2 Sep 2015 08:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-886) Upgrade to Xerces
 jboss-2.11.0.SP4 after merging pr#
In-Reply-To: <JIRA.12581595.1439824207000@Atlassian.JIRA>
References: <JIRA.12581595.1439824207000@Atlassian.JIRA>
	<JIRA.12581595.1439824207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581595.1439824207000.13961.1441198445469@Atlassian.JIRA>


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

Scott Marlow closed WFCORE-886.
-------------------------------
    Resolution: Done


> Upgrade to Xerces jboss-2.11.0.SP4 after merging pr#
> ----------------------------------------------------
>
>                 Key: WFCORE-886
>                 URL: https://issues.jboss.org/browse/WFCORE-886
>             Project: WildFly Core
>          Issue Type: Task
>          Components: XML Frameworks
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>
> After [https://github.com/jboss/xerces/pull/9] is merged, please release a jboss-2.11.0.SP4 (via https://github.com/jboss/xerces) and create a PR for wildfly-core.  [https://github.com/jboss/xerces/pull/9] is needed to pass the JAXB TCK.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 10:03:05 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 2 Sep 2015 10:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-946) CLI Hangs in 'quit'
In-Reply-To: <JIRA.12583585.1441202553000@Atlassian.JIRA>
References: <JIRA.12583585.1441202553000@Atlassian.JIRA>
	<JIRA.12583585.1441202553689@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583585.1441202553000.14131.1441202585311@Atlassian.JIRA>

Brian Stansberry created WFCORE-946:
---------------------------------------

             Summary: CLI Hangs in 'quit'
                 Key: WFCORE-946
                 URL: https://issues.jboss.org/browse/WFCORE-946
             Project: WildFly Core
          Issue Type: Feature Request
          Components: CLI
            Reporter: Brian Stansberry
            Assignee: Alexey Loubyansky
            Priority: Blocker
             Fix For: 2.0.0.CR1
         Attachments: quit-hang.txt

If you enter the 'quit' command, the CLI hangs.

I'll attach a thread dump.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 10:05:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Sep 2015 10:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.14141.1441202705348@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1956:
--------------------------------

No, all files will be removed. The info sender task will cause each coordinator to write its own information to the store again after a view change, based on {{info_writer_max_writes_after_view}} and {{info_writer_sleep_time}}. The former attribute governs the number of times this info is written, with a sleep (the latter attr) in-between.

> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 10:18:05 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 2 Sep 2015 10:18:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473860@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.14207.1441203485450@Atlassian.JIRA>

David Lloyd created ELY-282:
-------------------------------

             Summary: Formalize multiple credential support
                 Key: ELY-282
                 URL: https://issues.jboss.org/browse/ELY-282
             Project: WildFly Elytron
          Issue Type: Task
          Components: API / SPI, Realms
            Reporter: David Lloyd
            Priority: Critical
             Fix For: 1.1.0.Alpha1


Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:

# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 10:19:05 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 2 Sep 2015 10:19:05 -0400 (EDT)
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.14211.1441203545388@Atlassian.JIRA>


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

Kabir Khan moved WFCORE-862 to WFLY-5263:
-----------------------------------------

              Project: WildFly  (was: WildFly Core)
                  Key: WFLY-5263  (was: WFCORE-862)
          Component/s: JMX
                           (was: JMX)
    Affects Version/s: 10.0.0.Beta2
                           (was: 2.0.0.Alpha12)
        Fix Version/s: 10.0.0.CR1
                           (was: 2.0.0.CR1)


> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 10:19:05 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 2 Sep 2015 10:19:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.14214.1441203545454@Atlassian.JIRA>


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

David Lloyd updated ELY-282:
----------------------------
    Description: 
Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:

# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
#* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).


  was:
Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:

# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).




> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 10:24:05 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 2 Sep 2015 10:24:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-281) Investigate if it's possible to
 modify the OTP SASL mechanism and password implementation to make use of
 the credential verification API
In-Reply-To: <JIRA.12583493.1441140776000@Atlassian.JIRA>
References: <JIRA.12583493.1441140776000@Atlassian.JIRA>
	<JIRA.12583493.1441140776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583493.1441140776000.14232.1441203845257@Atlassian.JIRA>


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

David Lloyd commented on ELY-281:
---------------------------------

One possible slight modification to this approach might be to add a method to the realm identity indicating that authentication was completed - this would avoid the possible problem where a verification should not "count" towards the OTP authentication.

I can't think of a good solution to requiring realms to use {{PasswordFactory}}.  Ideally they *should* but I can't say for sure that they always *must*...

> Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-281
>                 URL: https://issues.jboss.org/browse/ELY-281
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds.
> Relevant chat discussion:
> {quote}
> \[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm
> \[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update
> \[8:43 AM\] Kabir Khan: That is what I had planned
> \[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally
> \[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible
> \[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though
> \[8:44 AM\] Kabir Khan: the first option is what stood out to me
> \[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 10:33:05 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 2 Sep 2015 10:33:05 -0400 (EDT)
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.14276.1441204385387@Atlassian.JIRA>


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

Kabir Khan commented on WFLY-5263:
----------------------------------

This turns out to be because the JSR 77 mbean server plugin does not filter out matches which do not match the wildcard (hence the move back to WFLY, I moved it to WFCORE when assuming that )

I am a bit stumped that this works in WF 9.0.0.CR1, since this code has been the same for a long time. Perhaps your config there is not using the jsr77 subsystem?

> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 11:00:07 2015
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Wed, 2 Sep 2015 11:00:07 -0400 (EDT)
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.14439.1441206007823@Atlassian.JIRA>


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

Cheng Fang resolved WFLY-5134.
------------------------------
    Resolution: Done


WFLY-5174 	Upgrade jberet-core to 1.2.0.Beta1 has been merged into WildFly 10

> 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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 11:08:05 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 2 Sep 2015 11:08:05 -0400 (EDT)
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.14505.1441206485463@Atlassian.JIRA>


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

Paul Ferraro reopened WFLY-5198:
--------------------------------


Reopening, due to identified performance issues with the distribution of a session's cache entries.

> 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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 11:16:05 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 2 Sep 2015 11:16:05 -0400 (EDT)
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.14592.1441206965600@Atlassian.JIRA>


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

Paul Ferraro edited comment on WFLY-5198 at 9/2/15 11:16 AM:
-------------------------------------------------------------

It should also be noted that the default session identifier length changed between EAP6 and WildFly from 16 bytes to 30 bytes.  This will have an impact on replication performance.  Any future tests should configure the session identifier length in WF to match that from EAP6.
e.g.
{code:xml}
<subsystem xmlns="urn:jboss:domain:undertow:3.0">
  <!-- ... -->
  <servlet-container name="default" session-id-length="16">
    <!-- ... -->
  </servlet-container>
  <!-- ... -->
</subsystem>
{code}


was (Author: pferraro):
It should also be noted that the default session identifier length changed between EAP6 and WildFly from 16 bytes to 30 bytes.  This will have an impact on replication performance.  Any future tests should configure the session identifier length in WF to match that from EAP6.

> 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
>
> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 11:22:05 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 2 Sep 2015 11:22:05 -0400 (EDT)
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.1441207301490@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583599.1441207301000.14611.1441207325664@Atlassian.JIRA>

James Perkins created WFLY-5264:
-----------------------------------

             Summary: 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 11:59:05 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 2 Sep 2015 11:59:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-946) CLI Hangs in 'quit'
In-Reply-To: <JIRA.12583585.1441202553000@Atlassian.JIRA>
References: <JIRA.12583585.1441202553000@Atlassian.JIRA>
	<JIRA.12583585.1441202553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583585.1441202553000.14828.1441209545316@Atlassian.JIRA>


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

Alexey Loubyansky reassigned WFCORE-946:
----------------------------------------

    Assignee: Joe Wertz  (was: Alexey Loubyansky)


Joe, could you please look into this? Thanks.

> CLI Hangs in 'quit'
> -------------------
>
>                 Key: WFCORE-946
>                 URL: https://issues.jboss.org/browse/WFCORE-946
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Joe Wertz
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>         Attachments: quit-hang.txt
>
>
> If you enter the 'quit' command, the CLI hangs.
> I'll attach a thread dump.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 11:59:05 2015
From: issues at jboss.org (Marcio Ricardo Hatzlhoffer Correia (JIRA))
Date: Wed, 2 Sep 2015 11:59:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5257) Unix Domain Socket Listener
	to Undertow
In-Reply-To: <JIRA.12583497.1441142941000@Atlassian.JIRA>
References: <JIRA.12583497.1441142941000@Atlassian.JIRA>
	<JIRA.12583497.1441142941000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583497.1441142941000.14831.1441209545383@Atlassian.JIRA>


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

Marcio Ricardo Hatzlhoffer Correia updated WFLY-5257:
-----------------------------------------------------
    Component/s: Web (Undertow)
                     (was: IO)


> Unix Domain Socket Listener to Undertow
> ---------------------------------------
>
>                 Key: WFLY-5257
>                 URL: https://issues.jboss.org/browse/WFLY-5257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>         Environment: Unix/Linux
>            Reporter: Marcio Ricardo Hatzlhoffer Correia
>            Assignee: Jason Greene
>
> For many cases, it's used an application like Apache or Nginx as a Reverse Proxy in front of Wildfly. As there is no option to use Unix Domain Socket, these applications use the TCP stack to redirect the connection to the Wildfly (Undertow) and it incurs a slight performance overhead. 
> In the case of a Reverse Proxy configuration where your upstream server is on the same machine, you can get better performance by skipping the TCP/Network stack and using Unix Domain Sockets. A Unix Domain Socket is communication mechanism to do inter-process messaging within the operating system kernel, using the file system as the name space.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 12:15:06 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 2 Sep 2015 12:15:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.14847.1441210506147@Atlassian.JIRA>


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

Jan Kalina commented on ELY-282:
--------------------------------

Mapper above solve situation when I am SASL server and I want to know which credential aquire from security realm.

But what if I am LDAP security realm and I see in LDAP entry few values of "userPassword" attribute? There would be same mapper, which would map attribute name + type of password ({CRYPT} for example) to labels?

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 12:16:05 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 2 Sep 2015 12:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.14853.1441210565320@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-282 at 9/2/15 12:15 PM:
---------------------------------------------------------

Mapper above solve situation when I am SASL server and I want to know which credential aquire from security realm.

But what if I am LDAP security realm and I see in LDAP entry few values of "userPassword" attribute? There would be same mapper, which would map attribute name + type of password (CRYPT for example) to labels?


was (Author: honza889):
Mapper above solve situation when I am SASL server and I want to know which credential aquire from security realm.

But what if I am LDAP security realm and I see in LDAP entry few values of "userPassword" attribute? There would be same mapper, which would map attribute name + type of password (CRYPT for example) to labels?

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 12:16:05 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 2 Sep 2015 12:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.14850.1441210565256@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-282 at 9/2/15 12:15 PM:
---------------------------------------------------------

Mapper above solve situation when I am SASL server and I want to know which credential aquire from security realm.

But what if I am LDAP security realm and I see in LDAP entry few values of "userPassword" attribute? There would be same mapper, which would map attribute name + type of password (CRYPT for example) to labels?


was (Author: honza889):
Mapper above solve situation when I am SASL server and I want to know which credential aquire from security realm.

But what if I am LDAP security realm and I see in LDAP entry few values of "userPassword" attribute? There would be same mapper, which would map attribute name + type of password ({CRYPT} for example) to labels?

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 12:46:05 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 2 Sep 2015 12:46:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.14906.1441212365279@Atlassian.JIRA>


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

David Lloyd commented on ELY-282:
---------------------------------

Your solution seems plausible to me (though I'm definitely not an LDAP expert - Darran or Pedro would probably have more useful feedback).

Another solution could be to map labels directly to attributes and have a mapping in that way.  Using this solution, only one standard userPassword would be supported; all other passwords would have to be in a custom attribute of some sort.


> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 12:58:05 2015
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 2 Sep 2015 12:58:05 -0400 (EDT)
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.1441213044614@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583605.1441213044000.14948.1441213085353@Atlassian.JIRA>

Peter Skopek created ELY-283:
--------------------------------

             Summary: 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: Peter Skopek


Investigate Elytron and gssproxy interoperability.

https://fedorahosted.org/gss-proxy/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 13:24:05 2015
From: issues at jboss.org (Nick Sawadsky (JIRA))
Date: Wed, 2 Sep 2015 13:24:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.14986.1441214645369@Atlassian.JIRA>


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

Nick Sawadsky commented on JGRP-1954:
-------------------------------------

I will take a shot at implementing the fix Thomas suggested. Would be great to get the fix in to 3.6.5, so I'll try to get on that today.

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 13:30:05 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Sep 2015 13:30:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-924) Factor out common code for
 management interface definitions.
In-Reply-To: <JIRA.12582790.1440672108000@Atlassian.JIRA>
References: <JIRA.12582790.1440672108000@Atlassian.JIRA>
	<JIRA.12582790.1440672108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582790.1440672108000.15011.1441215005670@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-924:
-----------------------------------------

Code changes within this branch https://github.com/darranl/wildfly-core/tree/WFCORE-924

This enables both common resource definitions for the attributes used in both standalone and domain mode and common base add handlers to handle those attributes.

> Factor out common code for management interface definitions.
> ------------------------------------------------------------
>
>                 Key: WFCORE-924
>                 URL: https://issues.jboss.org/browse/WFCORE-924
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha1
>
>
> These interfaces started off very simple and initially their attributes were fairly distinct due to the running mode they operated in - however as more and more attributes are added there is more common code than unique code and this is tending to mean all changes are being made in duplicate - double that if a change also impacts on the native definition.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 13:34:05 2015
From: issues at jboss.org (Nick Sawadsky (JIRA))
Date: Wed, 2 Sep 2015 13:34:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.15019.1441215245826@Atlassian.JIRA>


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

Nick Sawadsky commented on JGRP-1957:
-------------------------------------

Yes, I've tested this workaround and it seems to work:

- reduce the logical_addr_cache_expiration to 1 second
- reduce the logical_addr_cache_reaper_interval to 10 seconds
- increase the min_interval and max_interval for MERGE3 to 30 and 60 seconds, respectively
- set remove_all_files_on_view_change to true

With these settings, the expired nodes do seem to get removed from the file as expected. It would be nice to have a fix that did not require users to make these config changes, but I'm fine with pushing the issue to 3.6.6.


> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 13:40:05 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 2 Sep 2015 13:40:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.15022.1441215605313@Atlassian.JIRA>


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

Jan Kalina commented on ELY-282:
--------------------------------

In such case mapping of attribute+password type looks much better - in LDAP is usual to have different types of password in userPassword attribute. (diferentialted by prefix):
{code}userPassword: {SSHA}Ly8bkMMLGWOl8F/uGJDMLpTzy569cPEZ    =>    label = "userPassword-ssha"{code}

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 13:48:05 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 2 Sep 2015 13:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.15041.1441216085297@Atlassian.JIRA>


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

David Lloyd commented on ELY-282:
---------------------------------

If the prefix format is standardized in any way, you could directly map to it from the label.

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 15:01:05 2015
From: issues at jboss.org (Gilliard Cordeiro (JIRA))
Date: Wed, 2 Sep 2015 15:01:05 -0400 (EDT)
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.15189.1441220465673@Atlassian.JIRA>


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

Gilliard Cordeiro commented on WFLY-4754:
-----------------------------------------

Wildfly 8.2.2 and 9.0.2 will get this fix?

> 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
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 15:19:05 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Sep 2015 15:19:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-909) LdapLoginModule code has
 unnecessary BIND_CREDENTIAL constant
In-Reply-To: <JIRA.12582404.1440488382000@Atlassian.JIRA>
References: <JIRA.12582404.1440488382000@Atlassian.JIRA>
	<JIRA.12582404.1440488382000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582404.1440488382000.15244.1441221545488@Atlassian.JIRA>


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

Darran Lofthouse moved WFCORE-908 to SECURITY-909:
--------------------------------------------------

        Project: PicketBox   (was: WildFly Core)
            Key: SECURITY-909  (was: WFCORE-908)
       Workflow: classic default workflow  (was: GIT Pull Request workflow )
    Component/s: JBossSX
                     (was: Security)


> LdapLoginModule code has unnecessary BIND_CREDENTIAL constant
> -------------------------------------------------------------
>
>                 Key: SECURITY-909
>                 URL: https://issues.jboss.org/browse/SECURITY-909
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>            Priority: Minor
>
> The {{org.jboss.security.auth.spi.LdapLoginModule}} class contains unnecessary constant
> {code}
> private static final String BIND_CREDENTIAL = "bindCredential";
> {code}
> It's only used in {{traceLDAPEnv}} method which is responsible for masking passwords in module options. The "bindCredential" is not a valid option in this login module.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 15:20:05 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Sep 2015 15:20:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-909) LdapLoginModule code has
 unnecessary BIND_CREDENTIAL constant
In-Reply-To: <JIRA.12582404.1440488382000@Atlassian.JIRA>
References: <JIRA.12582404.1440488382000@Atlassian.JIRA>
	<JIRA.12582404.1440488382000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582404.1440488382000.15249.1441221605679@Atlassian.JIRA>


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

Darran Lofthouse reassigned SECURITY-909:
-----------------------------------------

    Assignee: Stefan Guilhen  (was: Darran Lofthouse)


> LdapLoginModule code has unnecessary BIND_CREDENTIAL constant
> -------------------------------------------------------------
>
>                 Key: SECURITY-909
>                 URL: https://issues.jboss.org/browse/SECURITY-909
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX
>            Reporter: Josef Cacek
>            Assignee: Stefan Guilhen
>            Priority: Minor
>
> The {{org.jboss.security.auth.spi.LdapLoginModule}} class contains unnecessary constant
> {code}
> private static final String BIND_CREDENTIAL = "bindCredential";
> {code}
> It's only used in {{traceLDAPEnv}} method which is responsible for masking passwords in module options. The "bindCredential" is not a valid option in this login module.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 15:20:06 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Sep 2015 15:20:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-947) Upgrade to WildFly Elytron
	1.0.0.Final
In-Reply-To: <JIRA.12583615.1441221606000@Atlassian.JIRA>
References: <JIRA.12583615.1441221606000@Atlassian.JIRA>
	<JIRA.12583615.1441221606156@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583615.1441221606000.15267.1441221606655@Atlassian.JIRA>

Darran Lofthouse created WFCORE-947:
---------------------------------------

             Summary: Upgrade to WildFly Elytron 1.0.0.Final
                 Key: WFCORE-947
                 URL: https://issues.jboss.org/browse/WFCORE-947
             Project: WildFly Core
          Issue Type: Component  Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 2.0.0.CR1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 16:48:05 2015
From: issues at jboss.org (Manuel Colchete (JIRA))
Date: Wed, 2 Sep 2015 16:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener
 request client certificate despite verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.15506.1441226885260@Atlassian.JIRA>


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

Manuel Colchete updated WFLY-5256:
----------------------------------
    Priority: Major  (was: Minor)


> HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5256
>                 URL: https://issues.jboss.org/browse/WFLY-5256
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Manuel Colchete
>            Assignee: Stuart Douglas
>
> HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 19:42:05 2015
From: issues at jboss.org (Nick Sawadsky (JIRA))
Date: Wed, 2 Sep 2015 19:42:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.15656.1441237325478@Atlassian.JIRA>


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

Nick Sawadsky commented on JGRP-1954:
-------------------------------------

Here is the pull request: https://github.com/belaban/JGroups/pull/233

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 20:38:05 2015
From: issues at jboss.org (Karsten Ohme (JIRA))
Date: Wed, 2 Sep 2015 20:38:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.15806.1441240685807@Atlassian.JIRA>


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

Karsten Ohme commented on JGRP-1956:
------------------------------------

Is it possible to define some sensible defaults for handling zombies, e.g. enabling remove_old_coords_on_view_change and remove_all_files_on_view_change? Otherwise a cron job has to be added to clean up stale files from time to time when server instances are crashing?
The default value for `info_writer_max_writes_after_view` is 2. Why is 1 not enough? Does it not try it until it succeeds?

> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 21:44:05 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 2 Sep 2015 21:44:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-948) Multiprocess wildcard
 read-resource-description does not work
In-Reply-To: <JIRA.12583632.1441244592000@Atlassian.JIRA>
References: <JIRA.12583632.1441244592000@Atlassian.JIRA>
	<JIRA.12583632.1441244592932@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583632.1441244592000.15936.1441244645212@Atlassian.JIRA>

Brian Stansberry created WFCORE-948:
---------------------------------------

             Summary: Multiprocess wildcard read-resource-description does not work
                 Key: WFCORE-948
                 URL: https://issues.jboss.org/browse/WFCORE-948
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta5
            Reporter: Brian Stansberry


{code}
[domain at localhost:9990 /] /host=master/server=*/interface=public:read-resource-description
{
    "outcome" => "failed",
    "result" => [
        {
            "address" => [
                ("host" => "master"),
                ("server" => "*"),
                ("interface" => "public")
            ],
            "outcome" => "failed",
            "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
            "rolled-back" => true
        },
        {
            "address" => [
                ("host" => "master"),
                ("server" => "server-one"),
                ("interface" => "public")
            ],
            "outcome" => "failed",
            "result" => undefined,
            "rolled-back" => true
        },
        {
            "address" => [
                ("host" => "master"),
                ("server" => "server-two"),
                ("interface" => "public")
            ],
            "outcome" => "failed",
            "result" => undefined,
            "rolled-back" => true
        }
    ],
    "failure-description" => "WFLYCTL0285: Operation read-resource-description invoked against multiple target addresses failed at address [
    (\"host\" => \"master\"),
    (\"server\" => \"*\"),
    (\"interface\" => \"public\")
] with failure description WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
    "rolled-back" => true
}
{code}

In the HC log:

{code}
[Host Controller] 20:37:28,277 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("read-resource-description") failed - address: ([
[Host Controller]     ("host" => "master"),
[Host Controller]     ("server" => "*"),
[Host Controller]     ("interface" => "public")
[Host Controller] ]): java.lang.NullPointerException
[Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.getResourceRegistrationCheckForAlias(ReadResourceDescriptionHandler.java:391)
[Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecuteInternal(ReadResourceDescriptionHandler.java:189)
[Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecute(ReadResourceDescriptionHandler.java:161)
[Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.access$300(ReadResourceDescriptionHandler.java:97)
[Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$2.execute(ReadResourceDescriptionHandler.java:411)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:854)
{code}

The handling for this doesn't have the stuff I did for WFCORE-282.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 22:11:05 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 2 Sep 2015 22:11:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-621) Support legacy slaves when
 invoking wildcard reads in a domain
In-Reply-To: <JIRA.12567601.1427988452000@Atlassian.JIRA>
References: <JIRA.12567601.1427988452000@Atlassian.JIRA>
	<JIRA.12567601.1427988452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567601.1427988452000.15938.1441246265190@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-621:
---------------------------------------

    Assignee: Brian Stansberry


> Support legacy slaves when invoking wildcard reads in a domain
> --------------------------------------------------------------
>
>                 Key: WFCORE-621
>                 URL: https://issues.jboss.org/browse/WFCORE-621
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> This is a follow-on to WFCORE-282.
> The WFCORE-282 solution will not work for requests with address patterns {code}/host=*/server=*{code} or {code}/host=somename/server=*{code} if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.)
> In particular, it won't work with slaves running EAP 6.x.
> The problem is with either of those address patterns the DC will send a request addressed to {code}/host=somename/server=*{code} to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them.
> Potentially this could be fixed by having the DC detect these patterns and not call {code}/host=somename/server=*{code}, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed Sep  2 22:12:05 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 2 Sep 2015 22:12:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.15940.1441246325246@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-628:
---------------------------------------

    Assignee: Brian Stansberry


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 01:09:05 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Thu, 3 Sep 2015 01:09:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.16108.1441256945647@Atlassian.JIRA>


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

Petr Kremensky moved JBEAP-981 to WFCORE-949:
---------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-949  (was: JBEAP-981)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: CLI
                       Domain Management
                           (was: CLI)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.Beta5
                           (was: 7.0.0.DR9)


> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: Alexey Loubyansky
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 01:13:05 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 3 Sep 2015 01:13:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.16136.1441257185454@Atlassian.JIRA>


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

Alexey Loubyansky reassigned WFCORE-949:
----------------------------------------

    Component/s:     (was: CLI)
       Assignee: Brian Stansberry  (was: Alexey Loubyansky)


> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: Brian Stansberry
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 01:21:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Sep 2015 01:21:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.16151.1441257665485@Atlassian.JIRA>


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

Bela Ban updated JGRP-1954:
---------------------------
    Fix Version/s: 3.6.5
                       (was: 3.6.6)


> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 01:23:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Sep 2015 01:23:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol
 fatal error on OpenStack Kilo
In-Reply-To: <JIRA.12582577.1440522225000@Atlassian.JIRA>
References: <JIRA.12582577.1440522225000@Atlassian.JIRA>
	<JIRA.12582577.1440522225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582577.1440522225000.16159.1441257785548@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1954.
----------------------------
    Resolution: Done


Nick implemented the scripting engine approach suggested by Thomas, thanks !

> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
>                 Key: JGRP-1954
>                 URL: https://issues.jboss.org/browse/JGRP-1954
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123  FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> 	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> 	at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> 	at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 01:48:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Sep 2015 01:48:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove
	failed members
In-Reply-To: <JIRA.12583194.1440809064000@Atlassian.JIRA>
References: <JIRA.12583194.1440809064000@Atlassian.JIRA>
	<JIRA.12583194.1440809064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583194.1440809064000.16183.1441259285566@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1956:
--------------------------------

By default, neither attribute is enabled. Especially {{remove_all_files_on_view_change}} causes more network traffic. I suggest enable {{remove_old_coords_on_view_change}} only for now, as this handles members getting killed with kill -9, but doesn't cause as much traffic as enabling the other attr.
Re {{info_writer_max_writes_after_view}}: yes, you're right, 1 should be good enough in most cases. 

> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
>                 Key: JGRP-1956
>                 URL: https://issues.jboss.org/browse/JGRP-1956
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Karsten Ohme
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 01:52:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Sep 2015 01:52:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.16187.1441259525302@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1957:
--------------------------------

What do you want me to change ?

> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.5
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 02:05:05 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Sep 2015 02:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.16215.1441260305711@Atlassian.JIRA>


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

Bela Ban updated JGRP-1957:
---------------------------
    Fix Version/s: 3.6.6
                       (was: 3.6.5)


Pushed into 3.6.6 for now, so I can release 3.6.5. Not clear though what the solution should be...

> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.6
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 02:43:05 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Sep 2015 02:43:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-899) Kie-ci sends MavenRequest
 without considering the repositories defined in user settings file
In-Reply-To: <JIRA.12583317.1441037294000@Atlassian.JIRA>
References: <JIRA.12583317.1441037294000@Atlassian.JIRA>
	<JIRA.12583317.1441037294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583317.1441037294000.16241.1441262585464@Atlassian.JIRA>


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

RH Bugzilla Integration updated DROOLS-899:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1259589
        Bugzilla Update: Perform


> Kie-ci sends MavenRequest without considering the repositories defined in user settings file
> --------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-899
>                 URL: https://issues.jboss.org/browse/DROOLS-899
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 03:47:05 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Sep 2015 03:47:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-882) Fix for SECURITY-868
 breaks flush-cache capability
In-Reply-To: <JIRA.12571084.1431074109000@Atlassian.JIRA>
References: <JIRA.12571084.1431074109000@Atlassian.JIRA>
	<JIRA.12571084.1431074109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571084.1431074109000.16394.1441266425466@Atlassian.JIRA>


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

RH Bugzilla Integration commented on SECURITY-882:
--------------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ASSIGNED to POST

> Fix for SECURITY-868 breaks flush-cache capability
> --------------------------------------------------
>
>                 Key: SECURITY-882
>                 URL: https://issues.jboss.org/browse/SECURITY-882
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: AS-Integration
>    Affects Versions: PicketBox_4_0_19.Final
>         Environment: EAP 6.3.3, JDV 6.1.0
>            Reporter: Hisanobu Okuda
>            Assignee: Stefan Guilhen
>
> The member field ThreadLocal<CompoundInfo> validatedDomainInfo was introduced for the fix of SECURITY-868. When you are authenticated, a valid security info is stored in the field thread-locally. Then, you flushes the JAAS cache via CLI or API in another thread, org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache() is invoked, but validatedDomainInfo is not flushed properly, since it is ThreadLocal. As a result, a cached security info is re-used unexpectedly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 03:47:05 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Sep 2015 03:47:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-868) Multithread issue when
 validate with cached hased password + nonce credential info from
 JBossCachedAuthenticationManager
In-Reply-To: <JIRA.12557748.1416453607000@Atlassian.JIRA>
References: <JIRA.12557748.1416453607000@Atlassian.JIRA>
	<JIRA.12557748.1416453607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557748.1416453607000.16401.1441266425655@Atlassian.JIRA>


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

RH Bugzilla Integration commented on SECURITY-868:
--------------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ASSIGNED to POST

> Multithread issue when validate with cached hased password + nonce credential  info from JBossCachedAuthenticationManager 
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-868
>                 URL: https://issues.jboss.org/browse/SECURITY-868
>             Project: PicketBox 
>          Issue Type: Task
>          Components: PicketBox
>            Reporter: Jim Ma
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_9_0.Final
>
>         Attachments: stacktraces.log
>
>
> When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager,  thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A,  the cached validation info won't work and following validation with cached credential will all fail. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Thu Sep  3 03:47:05 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Sep 2015 03:47:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-888) Revert changes made in
	SECURITY-868
In-Reply-To: <JIRA.12572261.1432134072000@Atlassian.JIRA>
References: <JIRA.12572261.1432134072000@Atlassian.JIRA>
	<JIRA.12572261.1432134072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572261.1432134072000.16405.1441266425789@Atlassian.JIRA>


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

RH Bugzilla Integration commented on SECURITY-888:
--------------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ASSIGNED to POST

> Revert changes made in SECURITY-868
> -----------------------------------
>
>                 Key: SECURITY-888
>                 URL: https://issues.jboss.org/browse/SECURITY-888
>             Project: PicketBox 
>          Issue Type: Task
>    Affects Versions: PicketBox_4_9_1.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_9_2.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 04:15:07 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Thu, 3 Sep 2015 04:15:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.16530.1441268107047@Atlassian.JIRA>


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

?? ? commented on DROOLS-880:
-----------------------------

My environment is below 
CPU : Intel(R) Xeon(R) CPU E5-2650
RAM : 128Gb
Linux Kernel : 2.6.32-431.el6.x86_64
Drools : 6.3.0.CR1
Rest Client : Soap UI
WAS: Wildfly 8.1.0 
Please, let me know your environment. If the problem is that in my environment, I want to know your environment.

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Thu Sep  3 04:20:06 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 3 Sep 2015 04:20:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5225) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.16540.1441268406308@Atlassian.JIRA>


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

Marek Kopeck? updated WFLY-5225:
--------------------------------
    Priority: Critical  (was: Major)


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-5225
>                 URL: https://issues.jboss.org/browse/WFLY-5225
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Thu Sep  3 04:23:05 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 3 Sep 2015 04:23:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5225) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.16543.1441268585401@Atlassian.JIRA>


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

Marek Kopeck? commented on WFLY-5225:
-------------------------------------

[~kabirkhan]: this issue is still valid for Wildfly master (it use WF-Core 2.0.0.Beta5). Do you have time estimation for this issue?

> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-5225
>                 URL: https://issues.jboss.org/browse/WFLY-5225
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Thu Sep  3 04:47:05 2015
From: issues at jboss.org (Vivek Hingorani (JIRA))
Date: Thu, 3 Sep 2015 04:47:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.16666.1441270025445@Atlassian.JIRA>


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

Vivek Hingorani reopened DROOLS-890:
------------------------------------


Did the patch locally in drools-core 6.2.0.Final jar but issue still exists. Not sure if patch was right and hence requesting to patch in drools 6.2.0.Final please

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 04:47:05 2015
From: issues at jboss.org (Vivek Hingorani (JIRA))
Date: Thu, 3 Sep 2015 04:47:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.16670.1441270025616@Atlassian.JIRA>


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

Vivek Hingorani commented on DROOLS-890:
----------------------------------------

Thanks a lot Mario for the fix.
I checked the drools.org site and still can't see Drools 6.3.0.Final.
Also we tried to reproduce the issue with Drools 6.2.0.Final and the same issue is there with drools 6.2.0.Final as well. Can you please provide the same patch on Drools6.2.0.Final as we would be using Drools 6.2.0.Final only in our project. 

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 04:55:05 2015
From: issues at jboss.org (David virgil naranjo (JIRA))
Date: Thu, 3 Sep 2015 04:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-901) Align spring version with
 the eap fuse layer spring version
In-Reply-To: <JIRA.12583663.1441270475000@Atlassian.JIRA>
References: <JIRA.12583663.1441270475000@Atlassian.JIRA>
	<JIRA.12583663.1441270475183@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583663.1441270475000.16704.1441270505328@Atlassian.JIRA>

David virgil naranjo created DROOLS-901:
-------------------------------------------

             Summary: Align spring version with the eap fuse layer spring version
                 Key: DROOLS-901
                 URL: https://issues.jboss.org/browse/DROOLS-901
             Project: Drools
          Issue Type: Enhancement
    Affects Versions: 6.3.0.Final
            Reporter: David virgil naranjo
            Assignee: Mark Proctor


Right now on drools it is used spring 3, while on the eap fuse layer it is used the version 4.1.6.RELEASE.

It wouldb e good to have the same version, because in that case some of the fuse-bxms-integ quickstarts could be deployed on eap.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 04:55:05 2015
From: issues at jboss.org (David virgil naranjo (JIRA))
Date: Thu, 3 Sep 2015 04:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-901) Align spring version with
 the eap fuse layer spring version
In-Reply-To: <JIRA.12583663.1441270475000@Atlassian.JIRA>
References: <JIRA.12583663.1441270475000@Atlassian.JIRA>
	<JIRA.12583663.1441270475000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583663.1441270475000.16708.1441270505465@Atlassian.JIRA>


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

David virgil naranjo reassigned DROOLS-901:
-------------------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)


> Align spring version with the eap fuse layer spring version
> -----------------------------------------------------------
>
>                 Key: DROOLS-901
>                 URL: https://issues.jboss.org/browse/DROOLS-901
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 6.3.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>
> Right now on drools it is used spring 3, while on the eap fuse layer it is used the version 4.1.6.RELEASE.
> It wouldb e good to have the same version, because in that case some of the fuse-bxms-integ quickstarts could be deployed on eap.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 05:09:05 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Thu, 3 Sep 2015 05:09:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-950) Embedded server started
 non-modular use first passed --jboss-home value only
In-Reply-To: <JIRA.12583667.1441271134000@Atlassian.JIRA>
References: <JIRA.12583667.1441271134000@Atlassian.JIRA>
	<JIRA.12583667.1441271134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583667.1441271134000.16797.1441271345347@Atlassian.JIRA>


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

Petr Kremensky moved JBEAP-986 to WFCORE-950:
---------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-950  (was: JBEAP-986)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Domain Management
                           (was: Domain Management)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.Beta4
                           (was: 7.0.0.DR9)


> Embedded server started non-modular use first passed --jboss-home value only
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-950
>                 URL: https://issues.jboss.org/browse/WFCORE-950
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Brian Stansberry
>
> First value passed as --jboss-home to embed server instance (must be an existing directory) is always used for modules lookup and server standard paths setup within single CLI session.
> # Use wrong directory on first try, use correct directory on second try, embedded instance still tries to boot from wrong directory
> {noformat}$ pwd
> /home/pkremens/workspace/jboss-eap-7.0/bin/client
> $ java -jar jboss-cli-client.jar 
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace/jboss-eap-7.0/bin
> Cannot start embedded server: WFLYEMB0014: Cannot load module org.jboss.vfs from: local module loader @500e80c2 (finder: local module finder @75670fc4 (roots: /home/pkremens/workspace/jboss-eap-7.0/bin/modules)): org.jboss.vfs:main
> # server still tries to use /home/pkremens/workspace/jboss-eap-7.0/bin
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace/jboss-eap-7.0    
> Cannot start embedded server: WFLYEMB0014: Cannot load module org.jboss.vfs from: local module loader @500e80c2 (finder: local module finder @75670fc4 (roots: /home/pkremens/workspace/jboss-eap-7.0/bin/modules)): org.jboss.vfs:main
> {noformat}
> # Try to manage multiple EAP distros
> {noformat}
> /home/pkremens/workspace2
> ??? eap1
> ??? ??? jboss-eap-7.0
> ??? eap2
>     ??? jboss-eap-7.0
> $ java -jar jboss-cli-client.jar 
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace2/eap1/jboss-eap-7.0 --server-config=eap1.xml --empty-config
> [standalone at embedded /] stop-embedded-server 
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace2/eap2/jboss-eap-7.0 --server-config=eap2.xml --empty-config
> # jboss.server.*.dir point to eap1, but should point to eap2
> [standalone at embedded /] /path=*:read-attribute(name=path)
> ...
>             "address" => [("path" => "jboss.server.log.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0
>             "address" => [("path" => "jboss.server.data.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/data"
>             "address" => [("path" => "jboss.server.base.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone"
>             "address" => [("path" => "jboss.server.config.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration"
>             "address" => [("path" => "jboss.server.temp.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/tmp"
>             "address" => [("path" => "jboss.controller.temp.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/tmp"
>             "address" => [("path" => "jboss.home.dir")],
>             "result" => "/home/pkremens/workspace2/eap2/jboss-eap-7.0"
> ...
> # Both configuration files were created in eap1 directory
> $ find /home/pkremens/workspace2 | grep eap[12].xml
> /home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration/eap2.xml
> /home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration/eap1.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Thu Sep  3 05:19:05 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 3 Sep 2015 05:19:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.16835.1441271945511@Atlassian.JIRA>


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

Mario Fusco commented on DROOLS-890:
------------------------------------

Drools 6.3.0.Final is not out yet indeed. It should be ready in 2 or 3 weeks. I don't know how to provide a patch. You could cherry-pick that commit and build Drools from sources, but at that point I suggest to do this directly from master.

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 05:21:05 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Thu, 3 Sep 2015 05:21:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-933) Embedded server start
 commands are lacking argument validation
In-Reply-To: <JIRA.12583128.1440766459000@Atlassian.JIRA>
References: <JIRA.12583128.1440766459000@Atlassian.JIRA>
	<JIRA.12583128.1440766459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583128.1440766459000.16848.1441272065523@Atlassian.JIRA>


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

Petr Kremensky commented on WFCORE-933:
---------------------------------------

Using configuration file without xml suffix blocks indefinitely, please take this into account during validation.
e.g.
{noformat}[disconnected /] embed-server --server-config=test --empty-config

"AeshProcess: 1 at 2471" prio=5 tid=0x14 nid=NA waiting
  java.lang.Thread.State: WAITING
	  at java.lang.Object.wait(Object.java:-1)
	  at java.lang.Object.wait(Object.java:502)
	  at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
	  at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
	  at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.start(EmbeddedStandAloneServerFactory.java:306)
	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
	  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.wildfly.core.embedded.EmbeddedServerReference.invokeOnServer(EmbeddedServerReference.java:80)
	  at org.wildfly.core.embedded.EmbeddedServerReference.start(EmbeddedServerReference.java:55)
	  at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:200)
	  at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
	  at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
	  at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
	  at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
	  at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
	  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}

> Embedded server start commands are lacking argument validation
> --------------------------------------------------------------
>
>                 Key: WFCORE-933
>                 URL: https://issues.jboss.org/browse/WFCORE-933
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>
> Commands for starting embedded instances are lacking argument validation.
> {noformat}[disconnected /] embed-server foo
> [standalone at embedded /]
> [disconnected /] embed-server foo -foo
> [standalone at embedded /]
> [disconnected /] embed-server foo --foo
> [standalone at embedded /]
> [standalone at embedded /] stop-embedded-server foo
> The command accepts 0 unnamed argument(s) but received: [foo]
> [standalone at embedded /] stop-embedded-server -foo
> Unrecognized arguments: [-foo]
> [standalone at embedded /] stop-embedded-server --foo
> Unrecognized arguments: [--foo]{noformat}
> Same case for embedded host controller.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 05:24:05 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 05:24:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5225) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.16856.1441272245436@Atlassian.JIRA>


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

Kabir Khan commented on WFLY-5225:
----------------------------------

I am looking into it, but have no idea what is going on yet, so I have no estimate. I noticed that current WildFly Core master on its own works properly, and the place where it prints out the expected error message is at the following location:
{code}
requiredCapabilityMissing():3710, ControllerLogger_$logger {org.jboss.as.controller.logging}
validateCapabilities():353, OperationContextImpl {org.jboss.as.controller}
stageCompleted():267, OperationContextImpl {org.jboss.as.controller}
processStages():602, AbstractOperationContext {org.jboss.as.controller}
executeOperation():362, AbstractOperationContext {org.jboss.as.controller}
{code}

On WildFly master built both with the core version from master, and a snapshot from the core master, it fails with the NPE earlier in validateCapabilities():
{code}
storeIncludes():127, IncludingResourceCapabilityContext {org.jboss.as.controller.capability.registry}
getIncludingContexts():74, IncludingResourceCapabilityContext {org.jboss.as.controller.capability.registry}
resolveCapabilities():587, CapabilityRegistry {org.jboss.as.controller}
validateCapabilityRegistry():1212, ModelControllerImpl$ManagementModelImpl {org.jboss.as.controller}
validateCapabilities():277, OperationContextImpl {org.jboss.as.controller}
stageCompleted():267, OperationContextImpl {org.jboss.as.controller}
processStages():602, AbstractOperationContext {org.jboss.as.controller}
executeOperation():362, AbstractOperationContext {org.jboss.as.controller}
{code}

A side-effect of the NPE was that the controller write lock never got released (i.e. why the remove was hanging) and has a fix at https://github.com/wildfly/wildfly-core/compare/wildfly:master...kabir:WFLY-5225?expand=1.

To reproduce the NPE, I have removed all the servers from my local host.xml, and trimmed down the domain.xml. I can reproduce the NPE with the following domain.xml:
{code}
<?xml version='1.0' encoding='UTF-8'?>

<domain xmlns="urn:jboss:domain:4.0">

    <extensions>
        <extension module="org.jboss.as.logging"/>
        <extension module="org.wildfly.extension.io"/>
        <extension module="org.wildfly.extension.undertow"/>
    </extensions>

    <system-properties>
        <property name="java.net.preferIPv4Stack" value="true"/>
    </system-properties>

    <management>
        <access-control provider="simple">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>
    </management>

    <profiles>
        <profile name="default">
            <subsystem xmlns="urn:jboss:domain:logging:3.0">
                <console-handler name="CONSOLE">
                    <level name="INFO"/>
                    <formatter>
                        <named-formatter name="COLOR-PATTERN"/>
                    </formatter>
                </console-handler>
                <periodic-rotating-file-handler name="FILE" autoflush="true">
                    <formatter>
                        <named-formatter name="PATTERN"/>
                    </formatter>
                    <file relative-to="jboss.server.log.dir" path="server.log"/>
                    <suffix value=".yyyy-MM-dd"/>
                    <append value="true"/>
                </periodic-rotating-file-handler>
                <logger category="com.arjuna">
                    <level name="WARN"/>
                </logger>
                <logger category="org.apache.tomcat.util.modeler">
                    <level name="WARN"/>
                </logger>
                <logger category="org.jboss.as.config">
                    <level name="DEBUG"/>
                </logger>
                <logger category="sun.rmi">
                    <level name="WARN"/>
                </logger>
                <root-logger>
                    <level name="INFO"/>
                    <handlers>
                        <handler name="CONSOLE"/>
                        <handler name="FILE"/>
                    </handlers>
                </root-logger>
                <formatter name="PATTERN">
                    <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
                </formatter>
                <formatter name="COLOR-PATTERN">
                    <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
                </formatter>
            </subsystem>
            <subsystem xmlns="urn:jboss:domain:io:1.1">
                <worker name="default"/>
                <buffer-pool name="default"/>
            </subsystem>
            <subsystem xmlns="urn:jboss:domain:undertow:3.0">
                <buffer-cache name="default"/>
                <server name="default-server">
                    <http-listener name="default" redirect-socket="https" socket-binding="http"/>
                    <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>
                <servlet-container name="default">
                    <jsp-config/>
                    <websockets/>
                </servlet-container>
                <handlers>
                    <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
                </handlers>
                <filters>
                    <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
                    <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
                </filters>
            </subsystem>
        </profile>
        <profile name="new"/>
    </profiles>

    <interfaces>
        <interface name="management"/>
        <interface name="public"/>
        <interface name="unsecure"/>
    </interfaces>

    <socket-binding-groups>
        <socket-binding-group name="standard-sockets" default-interface="public">
            <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
            <socket-binding name="http" port="${jboss.http.port:8080}"/>
            <socket-binding name="https" port="${jboss.https.port:8443}"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
                <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
    </socket-binding-groups>

    <server-groups>
        <server-group name="main-server-group" profile="default">
            <jvm name="default">
                <heap size="64m" max-size="512m"/>
            </jvm>
            <socket-binding-group ref="standard-sockets"/>
        </server-group>
    </server-groups>

</domain>
{code}

If I comment out the undertow subsystem, I get the expected "WFLYCTL0369: Required capabilities are not available: org.wildfly.domain.profile.nonsence in context 'profiles'" message.


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-5225
>                 URL: https://issues.jboss.org/browse/WFLY-5225
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Thu Sep  3 05:45:05 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 3 Sep 2015 05:45:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-951) LDAP context resource leaks
	in Picketbox
In-Reply-To: <JIRA.12583675.1441273456000@Atlassian.JIRA>
References: <JIRA.12583675.1441273456000@Atlassian.JIRA>
	<JIRA.12583675.1441273456236@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583675.1441273456000.16943.1441273505356@Atlassian.JIRA>

Josef Cacek created WFCORE-951:
----------------------------------

             Summary: LDAP context resource leaks in Picketbox
                 Key: WFCORE-951
                 URL: https://issues.jboss.org/browse/WFCORE-951
             Project: WildFly Core
          Issue Type: Bug
          Components: Security
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse
            Priority: Blocker


There are several {{InitialLdapContext}} resource leaks in LDAP related code in PicketBox.

The most critical is IMO leak in `LdapLoginModule.createLdapInitContext()` method. LDAP connections will stay open for customers who use administrators bind (i.e. {{java.naming.security.principal}} login module option for the Ldap login module).

The problematic code seems like:
{code:java}
InitialLdapContext ctx = null;
try
{
   //...
   ctx = new InitialLdapContext(env, null);
   if (PicketBoxLogger.LOGGER.isTraceEnabled())
   {
      PicketBoxLogger.LOGGER.traceSuccessfulLogInToLDAP(ctx.toString());
   }

   if (bindDN != null)
   {
      // Rebind the ctx to the bind dn/credentials for the roles searches
      PicketBoxLogger.LOGGER.traceRebindWithConfiguredPrincipal(bindDN);
      env.setProperty(Context.SECURITY_PRINCIPAL, bindDN);
      env.put(Context.SECURITY_CREDENTIALS, bindCredential);
      ctx = new InitialLdapContext(env, null);
   }
   // ...
}
finally
{
   // Close the context to release the connection
   if (ctx != null)
      ctx.close();
   // ...
}
{code}

The first constructed {{InitialLdapContext}} is not closed before creating the "admin context".

The other PicketBox classes which have weak handling of the {{InitialLdapContext}} are:
* {{LdapContextHandler}}
* {{LdapAttributeMappingProvider}}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 05:46:05 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 3 Sep 2015 05:46:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-951) LDAP context resource leaks
	in Picketbox
In-Reply-To: <JIRA.12583675.1441273456000@Atlassian.JIRA>
References: <JIRA.12583675.1441273456000@Atlassian.JIRA>
	<JIRA.12583675.1441273456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583675.1441273456000.16946.1441273565295@Atlassian.JIRA>


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

Josef Cacek updated WFCORE-951:
-------------------------------
    Affects Version/s: 2.0.0.Beta5


> LDAP context resource leaks in Picketbox
> ----------------------------------------
>
>                 Key: WFCORE-951
>                 URL: https://issues.jboss.org/browse/WFCORE-951
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> There are several {{InitialLdapContext}} resource leaks in LDAP related code in PicketBox.
> The most critical is IMO leak in `LdapLoginModule.createLdapInitContext()` method. LDAP connections will stay open for customers who use administrators bind (i.e. {{java.naming.security.principal}} login module option for the Ldap login module).
> The problematic code seems like:
> {code:java}
> InitialLdapContext ctx = null;
> try
> {
>    //...
>    ctx = new InitialLdapContext(env, null);
>    if (PicketBoxLogger.LOGGER.isTraceEnabled())
>    {
>       PicketBoxLogger.LOGGER.traceSuccessfulLogInToLDAP(ctx.toString());
>    }
>    if (bindDN != null)
>    {
>       // Rebind the ctx to the bind dn/credentials for the roles searches
>       PicketBoxLogger.LOGGER.traceRebindWithConfiguredPrincipal(bindDN);
>       env.setProperty(Context.SECURITY_PRINCIPAL, bindDN);
>       env.put(Context.SECURITY_CREDENTIALS, bindCredential);
>       ctx = new InitialLdapContext(env, null);
>    }
>    // ...
> }
> finally
> {
>    // Close the context to release the connection
>    if (ctx != null)
>       ctx.close();
>    // ...
> }
> {code}
> The first constructed {{InitialLdapContext}} is not closed before creating the "admin context".
> The other PicketBox classes which have weak handling of the {{InitialLdapContext}} are:
> * {{LdapContextHandler}}
> * {{LdapAttributeMappingProvider}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 05:49:05 2015
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 3 Sep 2015 05:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-885) World readable audit.log file
In-Reply-To: <JIRA.12581568.1439814262000@Atlassian.JIRA>
References: <JIRA.12581568.1439814262000@Atlassian.JIRA>
	<JIRA.12581568.1439814262000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581568.1439814262000.16961.1441273745482@Atlassian.JIRA>


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

Ivo Studensky updated WFCORE-885:
---------------------------------
         Component/s: Domain Management
                          (was: Security)
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1023


I've prepared a port of Peter's commit to WildFly Core. 
As the current audit log code looks differently to EAP, it has to be a bit restructured.

> World readable audit.log file
> -----------------------------
>
>                 Key: WFCORE-885
>                 URL: https://issues.jboss.org/browse/WFCORE-885
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta2
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Blocker
>
> Server logs sensitive information into a world readable audit.log file. This information could be used by a local attacker to gain otherwise protected information about user sessions etc.
> This issue was originally reported as CVE in https://bugzilla.redhat.com/show_bug.cgi?id=1063642. EAP 6.x branches are fixed but same issue occurs in EAP 7 again.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 06:10:05 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 06:10:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-284) Upgrade to WildFly Common
	1.0.0.Final
In-Reply-To: <JIRA.12583681.1441274996000@Atlassian.JIRA>
References: <JIRA.12583681.1441274996000@Atlassian.JIRA>
	<JIRA.12583681.1441274996716@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583681.1441274996000.17159.1441275005574@Atlassian.JIRA>

Darran Lofthouse created ELY-284:
------------------------------------

             Summary: Upgrade to WildFly Common 1.0.0.Final
                 Key: ELY-284
                 URL: https://issues.jboss.org/browse/ELY-284
             Project: WildFly Elytron
          Issue Type: Component  Upgrade
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 1.1.0.Alpha1, 1.0.0.Final


Tagged as critical as trying to avoid tagging WildFly Elytron 1.0.0.Final with an Alpha dependency,



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu Sep  3 08:32:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 3 Sep 2015 08:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-952) Use WildFly Common for null
	param checks
In-Reply-To: <JIRA.12583814.1441283514000@Atlassian.JIRA>
References: <JIRA.12583814.1441283514000@Atlassian.JIRA>
	<JIRA.12583814.1441283514101@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583814.1441283514000.89.1441283520331@Atlassian.JIRA>

David Lloyd created WFCORE-952:
----------------------------------

             Summary: Use WildFly Common for null param checks
                 Key: WFCORE-952
                 URL: https://issues.jboss.org/browse/WFCORE-952
             Project: WildFly Core
          Issue Type: Task
            Reporter: David Lloyd
            Priority: Minor
             Fix For: 3.0.0.Alpha1


For each module, do the following:
* Locate any/all null param check methods in the log msg
* Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
* Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 08:34:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 3 Sep 2015 08:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-953) Use WildFly Common for null
	param checks
In-Reply-To: <JIRA.12583815.1441283595000@Atlassian.JIRA>
References: <JIRA.12583815.1441283595000@Atlassian.JIRA>
	<JIRA.12583815.1441283595066@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583815.1441283595000.101.1441283640538@Atlassian.JIRA>

David Lloyd created WFCORE-953:
----------------------------------

             Summary: Use WildFly Common for null param checks
                 Key: WFCORE-953
                 URL: https://issues.jboss.org/browse/WFCORE-953
             Project: WildFly Core
          Issue Type: Task
            Reporter: David Lloyd
            Priority: Minor
             Fix For: 3.0.0.Alpha1


For each module, do the following:
* Locate any/all null param check methods in the log msg
* Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
* Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 08:34:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 3 Sep 2015 08:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5265) Use WildFly Common for null
	param checks
In-Reply-To: <JIRA.12583815.1441283595000@Atlassian.JIRA>
References: <JIRA.12583815.1441283595000@Atlassian.JIRA>
	<JIRA.12583815.1441283595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583815.1441283595000.106.1441283640640@Atlassian.JIRA>


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

David Lloyd moved WFCORE-953 to WFLY-5265:
------------------------------------------

          Project: WildFly  (was: WildFly Core)
              Key: WFLY-5265  (was: WFCORE-953)
    Fix Version/s: 11.0.0.Alpha1
                       (was: 3.0.0.Alpha1)


> Use WildFly Common for null param checks
> ----------------------------------------
>
>                 Key: WFLY-5265
>                 URL: https://issues.jboss.org/browse/WFLY-5265
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> For each module, do the following:
> * Locate any/all null param check methods in the log msg
> * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
> * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 08:38:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 3 Sep 2015 08:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.149.1441283880140@Atlassian.JIRA>


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

Jan Kalina commented on ELY-282:
--------------------------------

If not will mind, I will take *steps 1-5.* - this interface change is little blocking my current progress on LDAP modifiability.

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 08:55:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 3 Sep 2015 08:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.241.1441284900301@Atlassian.JIRA>


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

David Lloyd commented on ELY-282:
---------------------------------

That's fine as long as the tests pass (I suspect that implementing 1-5 will break tests if there's no 6-7, but maybe you can find a way around it).

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 08:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 08:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-950) Embedded server started
 non-modular use first passed --jboss-home value only
In-Reply-To: <JIRA.12583667.1441271134000@Atlassian.JIRA>
References: <JIRA.12583667.1441271134000@Atlassian.JIRA>
	<JIRA.12583667.1441271134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583667.1441271134000.287.1441285140730@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-950:
---------------------------------------

    Fix Version/s: 3.0.0.Alpha1
         Assignee: Ken Wills  (was: Brian Stansberry)


[~luck3y] I've scheduled this for 3 as I suspect it may not be easily solved, although it's fine to fix it for 2 if other stuff is done.

I suspect once all the modular classloading is set up once it can't be readily discarded.

A better failure would be good though.

> Embedded server started non-modular use first passed --jboss-home value only
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-950
>                 URL: https://issues.jboss.org/browse/WFCORE-950
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 3.0.0.Alpha1
>
>
> First value passed as --jboss-home to embed server instance (must be an existing directory) is always used for modules lookup and server standard paths setup within single CLI session.
> # Use wrong directory on first try, use correct directory on second try, embedded instance still tries to boot from wrong directory
> {noformat}$ pwd
> /home/pkremens/workspace/jboss-eap-7.0/bin/client
> $ java -jar jboss-cli-client.jar 
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace/jboss-eap-7.0/bin
> Cannot start embedded server: WFLYEMB0014: Cannot load module org.jboss.vfs from: local module loader @500e80c2 (finder: local module finder @75670fc4 (roots: /home/pkremens/workspace/jboss-eap-7.0/bin/modules)): org.jboss.vfs:main
> # server still tries to use /home/pkremens/workspace/jboss-eap-7.0/bin
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace/jboss-eap-7.0    
> Cannot start embedded server: WFLYEMB0014: Cannot load module org.jboss.vfs from: local module loader @500e80c2 (finder: local module finder @75670fc4 (roots: /home/pkremens/workspace/jboss-eap-7.0/bin/modules)): org.jboss.vfs:main
> {noformat}
> # Try to manage multiple EAP distros
> {noformat}
> /home/pkremens/workspace2
> ??? eap1
> ??? ??? jboss-eap-7.0
> ??? eap2
>     ??? jboss-eap-7.0
> $ java -jar jboss-cli-client.jar 
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace2/eap1/jboss-eap-7.0 --server-config=eap1.xml --empty-config
> [standalone at embedded /] stop-embedded-server 
> [disconnected /] embed-server --jboss-home=/home/pkremens/workspace2/eap2/jboss-eap-7.0 --server-config=eap2.xml --empty-config
> # jboss.server.*.dir point to eap1, but should point to eap2
> [standalone at embedded /] /path=*:read-attribute(name=path)
> ...
>             "address" => [("path" => "jboss.server.log.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0
>             "address" => [("path" => "jboss.server.data.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/data"
>             "address" => [("path" => "jboss.server.base.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone"
>             "address" => [("path" => "jboss.server.config.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration"
>             "address" => [("path" => "jboss.server.temp.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/tmp"
>             "address" => [("path" => "jboss.controller.temp.dir")],
>             "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/tmp"
>             "address" => [("path" => "jboss.home.dir")],
>             "result" => "/home/pkremens/workspace2/eap2/jboss-eap-7.0"
> ...
> # Both configuration files were created in eap1 directory
> $ find /home/pkremens/workspace2 | grep eap[12].xml
> /home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration/eap2.xml
> /home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration/eap1.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 09:10:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 3 Sep 2015 09:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.355.1441285800401@Atlassian.JIRA>


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

David Lloyd updated ELY-282:
----------------------------
    Description: 
Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:

# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
#* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).


  was:
Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:

# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
#* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).




> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:30:00 2015
From: issues at jboss.org (=?UTF-8?Q?jukka_sirvi=C3=B6_=28JIRA=29?=)
Date: Thu, 3 Sep 2015 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3543) Definition of error pages in
	WEB-INF
In-Reply-To: <JIRA.12544675.1403608089000@Atlassian.JIRA>
References: <JIRA.12544675.1403608089000@Atlassian.JIRA>
	<JIRA.12544675.1403608089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544675.1403608089000.463.1441287000247@Atlassian.JIRA>


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

jukka sirvi? commented on WFLY-3543:
------------------------------------

seems still open issue in 9.0.1-Final

> Definition of error pages in WEB-INF
> ------------------------------------
>
>                 Key: WFLY-3543
>                 URL: https://issues.jboss.org/browse/WFLY-3543
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Final, 8.1.0.Final
>            Reporter: Christian K?lle
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Alpha1
>
>
> Under Jboss5-7 it was no problem to do the following in web.xml:
>  
> <error-page>
>   <error-code>404</error-code>
>   <location>/WEB-INF/errors/dynamic_error.jsp</location>
> </error-page>
> <error-page>
>   <error-code>500</error-code>
> <location>/WEB-INF/errors/staticFatalError.html</location>
> </error-page>
>  
> If a generic exception is now thrown from a JSF page the behavior is as follows:
> 8.0 : stack overflow exceptions in undertow code; a blank white page in browser
> 8.1 : 404 for the error template itself; white page with small 404 text in top left
>  
> If the static html and jsp are located outside the WEB-INF everything works
> normally.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 09:45:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 3 Sep 2015 09:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.511.1441287900672@Atlassian.JIRA>


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

Mario Fusco resolved DROOLS-890.
--------------------------------
    Resolution: Done


Any reason why you reopened this issue?

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:47:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 3 Sep 2015 09:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5160) SingletonDeployment*TestCase
	fail on RHEL7
In-Reply-To: <JIRA.12582123.1440154452000@Atlassian.JIRA>
References: <JIRA.12582123.1440154452000@Atlassian.JIRA>
	<JIRA.12582123.1440154452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582123.1440154452000.574.1441288020579@Atlassian.JIRA>


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

Paul Ferraro commented on WFLY-5160:
------------------------------------

[~mkopecky] This is not a WF master job.

> SingletonDeployment*TestCase fail on RHEL7
> ------------------------------------------
>
>                 Key: WFLY-5160
>                 URL: https://issues.jboss.org/browse/WFLY-5160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta2
>
>
> *Description of problem:*
> * Two tests fail with "expected:<405> but was:<200>" error
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentJBossAllTestCase(SYNC-tcp)#test
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentDescriptorTestCase(SYNC-tcp)#test
> *How reproducible:*
> * RHEL7
> * IBM JDK 8, Oracle JDK 8, Open JDK 8
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dtest=SingletonDeploymentJBossAllTestCase,SingletonDeploymentDescriptorTestCase -DfailIfNoTests=false -Dts.clustering
> *Actual results:*
> {noformat}
> java.lang.AssertionError: expected:<405> but was:<200>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.junit.Assert.assertEquals(Assert.java:542)
> 	at org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentTestCase.test(SingletonDeploymentTestCase.java:84)
> 	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.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$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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 	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.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.createTestContext(ContainerEventController.java:129)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor5.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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: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: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:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No failures in test case.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 09:48:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 3 Sep 2015 09:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5160) SingletonDeployment*TestCase
	fail on RHEL7
In-Reply-To: <JIRA.12582123.1440154452000@Atlassian.JIRA>
References: <JIRA.12582123.1440154452000@Atlassian.JIRA>
	<JIRA.12582123.1440154452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582123.1440154452000.579.1441288080249@Atlassian.JIRA>


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

Paul Ferraro closed WFLY-5160.
------------------------------
    Resolution: Done


> SingletonDeployment*TestCase fail on RHEL7
> ------------------------------------------
>
>                 Key: WFLY-5160
>                 URL: https://issues.jboss.org/browse/WFLY-5160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta2
>
>
> *Description of problem:*
> * Two tests fail with "expected:<405> but was:<200>" error
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentJBossAllTestCase(SYNC-tcp)#test
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentDescriptorTestCase(SYNC-tcp)#test
> *How reproducible:*
> * RHEL7
> * IBM JDK 8, Oracle JDK 8, Open JDK 8
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dtest=SingletonDeploymentJBossAllTestCase,SingletonDeploymentDescriptorTestCase -DfailIfNoTests=false -Dts.clustering
> *Actual results:*
> {noformat}
> java.lang.AssertionError: expected:<405> but was:<200>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.junit.Assert.assertEquals(Assert.java:542)
> 	at org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentTestCase.test(SingletonDeploymentTestCase.java:84)
> 	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.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$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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 	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.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.createTestContext(ContainerEventController.java:129)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor5.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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: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: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:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No failures in test case.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 09:49:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 09:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-836)
 PersistentResourceXMLDescription should mashall default values by default
In-Reply-To: <JIRA.12579199.1437666691000@Atlassian.JIRA>
References: <JIRA.12579199.1437666691000@Atlassian.JIRA>
	<JIRA.12579199.1437666691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579199.1437666691000.583.1441288140253@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-836:
------------------------------------
    Priority: Blocker  (was: Critical)


> PersistentResourceXMLDescription should mashall default values by default
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-836
>                 URL: https://issues.jboss.org/browse/WFCORE-836
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>
> marshalDefaults  should be true by default in parser.
> Also we would need an option to override this in parser definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:51:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 09:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-622) DomainOperationContext
 transformation assumes slave host and slave host's servers receive the same
 ops
In-Reply-To: <JIRA.12567626.1428005915000@Atlassian.JIRA>
References: <JIRA.12567626.1428005915000@Atlassian.JIRA>
	<JIRA.12567626.1428005915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567626.1428005915000.593.1441288260870@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-622:
------------------------------------
    Fix Version/s:     (was: 2.0.0.CR1)


> DomainOperationContext transformation assumes slave host and slave host's servers receive the same ops
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-622
>                 URL: https://issues.jboss.org/browse/WFCORE-622
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>
> https://github.com/wildfly/wildfly-core/commit/f5c516f2#diff-dc2038399fc72656590c09fe73305791R151 assumes that the result transformer for the host request is appropriate for use with the subsequent requests to that host's servers during domain rollout.
> That's a shaky supposition, as the server ops generated from a host request have no fixed relationship to the host request itself. Alignment is the norm but not a rule. In particular it can faill apart with composite ops where some steps in the composite are not relevant to all hosts.
> Without this extra transformation, test at [1] fails. This indicates the server op is not getting the transformation registered at [2] applied. But if it's not getting the result transformation applied, wouldn't that mean relevant operation transformation isn't being applied as well? 
> [1] https://github.com/wildfly/wildfly-core/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/suites/OperationTransformationTestCase.java#L226
> [2] https://github.com/wildfly/wildfly-core/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/extension/VersionedExtension2.java#L108



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 09:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-701) Inconsistent domain server
 status reports between server-config resource and server resource
In-Reply-To: <JIRA.12572117.1432047977000@Atlassian.JIRA>
References: <JIRA.12572117.1432047977000@Atlassian.JIRA>
	<JIRA.12572117.1432047977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572117.1432047977000.596.1441288320202@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-701:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR1)


> Inconsistent domain server status reports between server-config resource and server resource
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-701
>                 URL: https://issues.jboss.org/browse/WFCORE-701
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.CR4, 2.0.0.Alpha2
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Alpha1
>
>
> When a managed server fails in some way, the server status reporting is inconsistent between the /host=<host>/server-config=<server> resources and the /host=<host>/server=<server> resource.
> To reproduce, run domain.sh, find the pid of a server process, and kill -9 <thepid>. Then with the CLI:
> {code}
> [domain at localhost:9990 /] /host=master/server-config=server-two:read-attribute(name=status)
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> [domain at localhost:9990 /] /host=master/server=server-two:read-attribute(name=server-state)
> {
>     "outcome" => "success",
>     "result" => "STOPPED"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 09:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.600.1441288320285@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-756:
------------------------------------
    Priority: Critical  (was: Major)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:54:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 09:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-311) Better error message if
 authentication is required to connect to the master but no realm is
 associated on the slave
In-Reply-To: <JIRA.12533525.1393517943000@Atlassian.JIRA>
References: <JIRA.12533525.1393517943000@Atlassian.JIRA>
	<JIRA.12533525.1393517943000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533525.1393517943000.614.1441288440110@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-311:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR1)


> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-311
>                 URL: https://issues.jboss.org/browse/WFCORE-311
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>         Environment: RH EL 6.3 - JBoss EAP 6.2
>            Reporter: Riccardo Benvenuti
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 3.0.0.Alpha1
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
>    <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
>   JAVA: /usr/java/jdk1.7.0_51/bin/java
>   JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly 
> <domain-controller>
>    <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:56:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 3 Sep 2015 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5266) Upgrade JGroups to 3.6.5.Final
In-Reply-To: <JIRA.12583837.1441288506000@Atlassian.JIRA>
References: <JIRA.12583837.1441288506000@Atlassian.JIRA>
	<JIRA.12583837.1441288506629@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583837.1441288506000.617.1441288560414@Atlassian.JIRA>

Paul Ferraro created WFLY-5266:
----------------------------------

             Summary: Upgrade JGroups to 3.6.5.Final
                 Key: WFLY-5266
                 URL: https://issues.jboss.org/browse/WFLY-5266
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:56:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 3 Sep 2015 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5267) Upgrade JGroups to 3.6.5.Final
In-Reply-To: <JIRA.12583838.1441288514000@Atlassian.JIRA>
References: <JIRA.12583838.1441288514000@Atlassian.JIRA>
	<JIRA.12583838.1441288514176@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583838.1441288514000.621.1441288560524@Atlassian.JIRA>

Paul Ferraro created WFLY-5267:
----------------------------------

             Summary: Upgrade JGroups to 3.6.5.Final
                 Key: WFLY-5267
                 URL: https://issues.jboss.org/browse/WFLY-5267
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 09:56:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-688) Remove
	ServerEnvironment.getModulesDir()
In-Reply-To: <JIRA.12464998.1335367561000@Atlassian.JIRA>
References: <JIRA.12464998.1335367561000@Atlassian.JIRA>
	<JIRA.12464998.1335367561000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464998.1335367561000.629.1441288560966@Atlassian.JIRA>


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

Brian Stansberry closed WFCORE-688.
-----------------------------------
    Fix Version/s:     (was: 2.0.0.CR1)
       Resolution: Won't Fix


I don't think it's worth it to deal with this, and I don't want to leave it hanging around just in case I change my mind.

> Remove ServerEnvironment.getModulesDir()
> ----------------------------------------
>
>                 Key: WFCORE-688
>                 URL: https://issues.jboss.org/browse/WFCORE-688
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Server
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> This method was deprecated in 7.1.0 and the OSGi subsystem is removing the only known use of it in 7.1.2. Remove the method in 7.2.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 10:04:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 3 Sep 2015 10:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-868) CLI if/else is not handling
 special characters strings with parenthesis
In-Reply-To: <JIRA.12580331.1438762375000@Atlassian.JIRA>
References: <JIRA.12580331.1438762375000@Atlassian.JIRA>
	<JIRA.12580331.1438762375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580331.1438762375000.701.1441289040732@Atlassian.JIRA>


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

Tomas Hofman reopened WFCORE-868:
---------------------------------


> CLI if/else is not handling special characters strings with parenthesis
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-868
>                 URL: https://issues.jboss.org/browse/WFCORE-868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Tomas Hofman
>            Assignee: Tomas Hofman
>
> When using CLI if-else scripting that uses a string that contains parenthesis it fails with the following message:
> Failed to handle 'if (outcome == success && result.value != "a64180c0)e7187af86b435229de904104") of /system-property=test:read-resource': Unexpected operation at 49 in '(outcome == success && result.value != "a64180c0)e7187af86b435229de904104")'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 10:17:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 3 Sep 2015 10:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5266) Upgrade JGroups to 3.6.5.Final
In-Reply-To: <JIRA.12583837.1441288506000@Atlassian.JIRA>
References: <JIRA.12583837.1441288506000@Atlassian.JIRA>
	<JIRA.12583837.1441288506000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583837.1441288506000.721.1441289820363@Atlassian.JIRA>


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

Paul Ferraro closed WFLY-5266.
------------------------------
    Resolution: Duplicate Issue


Not sure why jira created this twice....

> Upgrade JGroups to 3.6.5.Final
> ------------------------------
>
>                 Key: WFLY-5266
>                 URL: https://issues.jboss.org/browse/WFLY-5266
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 10:19:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 3 Sep 2015 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5267) Upgrade JGroups to 3.6.5.Final
In-Reply-To: <JIRA.12583838.1441288514000@Atlassian.JIRA>
References: <JIRA.12583838.1441288514000@Atlassian.JIRA>
	<JIRA.12583838.1441288514000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583838.1441288514000.728.1441289940214@Atlassian.JIRA>


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

Paul Ferraro closed WFLY-5267.
------------------------------
    Resolution: Duplicate Issue


Ugh - I created this already.

> Upgrade JGroups to 3.6.5.Final
> ------------------------------
>
>                 Key: WFLY-5267
>                 URL: https://issues.jboss.org/browse/WFLY-5267
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 10:31:01 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 10:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5268) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583843.1441290607000@Atlassian.JIRA>
References: <JIRA.12583843.1441290607000@Atlassian.JIRA>
	<JIRA.12583843.1441290607255@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583843.1441290607000.778.1441290661513@Atlassian.JIRA>

Kabir Khan created WFLY-5268:
--------------------------------

             Summary: Server is not responding after attempt to set parent of profile to non-existent profile
                 Key: WFLY-5268
                 URL: https://issues.jboss.org/browse/WFLY-5268
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 10.0.0.Beta2
            Reporter: Marek Kopeck?
            Assignee: Kabir Khan
            Priority: Critical


*Description of problem:*
Server is not responding after attempt to set parent of profile to non-existent profile. 

Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.

This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.

Priority of this jira tends to be critical.

*How reproducible:*
Always

*Steps to Reproduce (profile):*
# Get fresh EAP
# ./domain.sh
# ./jboss-cli.sh
## /profile=new:add()
## /profile=new:write-attribute(name=includes,value=\[nonsence\])
## /profile=new:remove

*Actual results:*
{noformat}
[domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
{
    "outcome" => "failed",
    "failure-description" => "java.lang.NullPointerException:null"
}
[domain at localhost:9990 /] /profile=new:remove

{noformat}
* server needs to be restarted

*Expected results:*
{noformat}
[domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
    org.wildfly.domain.profile.nonsence in context 'profiles'"},
    "rolled-back" => true
}
[domain at localhost:9990 /] /profile=new:remove
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
{noformat}

*Steps to reproduce (socket-binding-group):*
# Get fresh EAP
# ./domain.sh
# ./jboss-cli.sh
## /profile=new:add()
## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 10:31:01 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 10:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-954) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583843.1441290607000@Atlassian.JIRA>
References: <JIRA.12583843.1441290607000@Atlassian.JIRA>
	<JIRA.12583843.1441290607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583843.1441290607000.782.1441290661659@Atlassian.JIRA>


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

Kabir Khan moved WFLY-5268 to WFCORE-954:
-----------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-954  (was: WFLY-5268)
          Component/s: Domain Management
                           (was: CLI)
    Affects Version/s: 2.0.0.Beta5
                           (was: 10.0.0.Beta2)


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-954
>                 URL: https://issues.jboss.org/browse/WFCORE-954
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 10:31:01 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 10:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-954) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583843.1441290607000@Atlassian.JIRA>
References: <JIRA.12583843.1441290607000@Atlassian.JIRA>
	<JIRA.12583843.1441290607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583843.1441290607000.786.1441290661744@Atlassian.JIRA>


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

Kabir Khan updated WFCORE-954:
------------------------------
    Fix Version/s: 2.0.0.CR1


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-954
>                 URL: https://issues.jboss.org/browse/WFCORE-954
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 10:32:02 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 10:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-954) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583843.1441290607000@Atlassian.JIRA>
References: <JIRA.12583843.1441290607000@Atlassian.JIRA>
	<JIRA.12583843.1441290607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583843.1441290607000.824.1441290722004@Atlassian.JIRA>


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

Kabir Khan updated WFCORE-954:
------------------------------
    Description: 
This is a clone of WFLY-5225 to make sure that if the fix is in core, that we track it with this one.

*Description of problem:*
Server is not responding after attempt to set parent of profile to non-existent profile. 

Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.

This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.

Priority of this jira tends to be critical.

*How reproducible:*
Always

*Steps to Reproduce (profile):*
# Get fresh EAP
# ./domain.sh
# ./jboss-cli.sh
## /profile=new:add()
## /profile=new:write-attribute(name=includes,value=\[nonsence\])
## /profile=new:remove

*Actual results:*
{noformat}
[domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
{
    "outcome" => "failed",
    "failure-description" => "java.lang.NullPointerException:null"
}
[domain at localhost:9990 /] /profile=new:remove

{noformat}
* server needs to be restarted

*Expected results:*
{noformat}
[domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
    org.wildfly.domain.profile.nonsence in context 'profiles'"},
    "rolled-back" => true
}
[domain at localhost:9990 /] /profile=new:remove
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
{noformat}

*Steps to reproduce (socket-binding-group):*
# Get fresh EAP
# ./domain.sh
# ./jboss-cli.sh
## /profile=new:add()
## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
## /profile=new:remove

  was:
*Description of problem:*
Server is not responding after attempt to set parent of profile to non-existent profile. 

Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.

This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.

Priority of this jira tends to be critical.

*How reproducible:*
Always

*Steps to Reproduce (profile):*
# Get fresh EAP
# ./domain.sh
# ./jboss-cli.sh
## /profile=new:add()
## /profile=new:write-attribute(name=includes,value=\[nonsence\])
## /profile=new:remove

*Actual results:*
{noformat}
[domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
{
    "outcome" => "failed",
    "failure-description" => "java.lang.NullPointerException:null"
}
[domain at localhost:9990 /] /profile=new:remove

{noformat}
* server needs to be restarted

*Expected results:*
{noformat}
[domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
    org.wildfly.domain.profile.nonsence in context 'profiles'"},
    "rolled-back" => true
}
[domain at localhost:9990 /] /profile=new:remove
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
{noformat}

*Steps to reproduce (socket-binding-group):*
# Get fresh EAP
# ./domain.sh
# ./jboss-cli.sh
## /profile=new:add()
## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
## /profile=new:remove



> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-954
>                 URL: https://issues.jboss.org/browse/WFCORE-954
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> This is a clone of WFLY-5225 to make sure that if the fix is in core, that we track it with this one.
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 10:37:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Sep 2015 10:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-868) CLI if/else is not handling
 special characters strings with parenthesis
In-Reply-To: <JIRA.12580331.1438762375000@Atlassian.JIRA>
References: <JIRA.12580331.1438762375000@Atlassian.JIRA>
	<JIRA.12580331.1438762375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580331.1438762375000.841.1441291020166@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFCORE-868:
------------------------------------------------

Tomas Hofman <thofman at redhat.com> changed the Status of [bug 1249773|https://bugzilla.redhat.com/show_bug.cgi?id=1249773] from ASSIGNED to NEW

> CLI if/else is not handling special characters strings with parenthesis
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-868
>                 URL: https://issues.jboss.org/browse/WFCORE-868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Tomas Hofman
>            Assignee: Tomas Hofman
>
> When using CLI if-else scripting that uses a string that contains parenthesis it fails with the following message:
> Failed to handle 'if (outcome == success && result.value != "a64180c0)e7187af86b435229de904104") of /system-property=test:read-resource': Unexpected operation at 49 in '(outcome == success && result.value != "a64180c0)e7187af86b435229de904104")'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 10:40:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 3 Sep 2015 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-868) CLI if/else is not handling
 special characters strings with parenthesis
In-Reply-To: <JIRA.12580331.1438762375000@Atlassian.JIRA>
References: <JIRA.12580331.1438762375000@Atlassian.JIRA>
	<JIRA.12580331.1438762375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580331.1438762375000.864.1441291200419@Atlassian.JIRA>


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

Tomas Hofman reassigned WFCORE-868:
-----------------------------------

    Assignee: Alessio Soldano  (was: Tomas Hofman)


> CLI if/else is not handling special characters strings with parenthesis
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-868
>                 URL: https://issues.jboss.org/browse/WFCORE-868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Tomas Hofman
>            Assignee: Alessio Soldano
>
> When using CLI if-else scripting that uses a string that contains parenthesis it fails with the following message:
> Failed to handle 'if (outcome == success && result.value != "a64180c0)e7187af86b435229de904104") of /system-property=test:read-resource': Unexpected operation at 49 in '(outcome == success && result.value != "a64180c0)e7187af86b435229de904104")'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 10:41:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 3 Sep 2015 10:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5160) SingletonDeployment*TestCase
	fail on RHEL7
In-Reply-To: <JIRA.12582123.1440154452000@Atlassian.JIRA>
References: <JIRA.12582123.1440154452000@Atlassian.JIRA>
	<JIRA.12582123.1440154452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582123.1440154452000.875.1441291260470@Atlassian.JIRA>


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

Radoslav Husar reopened WFLY-5160:
----------------------------------
      Assignee: Radoslav Husar  (was: Paul Ferraro)


I will look at this.

> SingletonDeployment*TestCase fail on RHEL7
> ------------------------------------------
>
>                 Key: WFLY-5160
>                 URL: https://issues.jboss.org/browse/WFLY-5160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Beta2
>
>
> *Description of problem:*
> * Two tests fail with "expected:<405> but was:<200>" error
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentJBossAllTestCase(SYNC-tcp)#test
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentDescriptorTestCase(SYNC-tcp)#test
> *How reproducible:*
> * RHEL7
> * IBM JDK 8, Oracle JDK 8, Open JDK 8
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dtest=SingletonDeploymentJBossAllTestCase,SingletonDeploymentDescriptorTestCase -DfailIfNoTests=false -Dts.clustering
> *Actual results:*
> {noformat}
> java.lang.AssertionError: expected:<405> but was:<200>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.junit.Assert.assertEquals(Assert.java:542)
> 	at org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentTestCase.test(SingletonDeploymentTestCase.java:84)
> 	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.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$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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 	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.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.createTestContext(ContainerEventController.java:129)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.GeneratedMethodAccessor5.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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.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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	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: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: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:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No failures in test case.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 10:52:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5265) Use WildFly Common for null
	param checks
In-Reply-To: <JIRA.12583815.1441283595000@Atlassian.JIRA>
References: <JIRA.12583815.1441283595000@Atlassian.JIRA>
	<JIRA.12583815.1441283595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583815.1441283595000.964.1441291920613@Atlassian.JIRA>


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

Darran Lofthouse commented on WFLY-5265:
----------------------------------------

Probably worth noting checkNotNullParan returns the value checked so the use of this method can be inlined.

> Use WildFly Common for null param checks
> ----------------------------------------
>
>                 Key: WFLY-5265
>                 URL: https://issues.jboss.org/browse/WFLY-5265
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> For each module, do the following:
> * Locate any/all null param check methods in the log msg
> * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
> * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 10:52:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-952) Use WildFly Common for null
	param checks
In-Reply-To: <JIRA.12583814.1441283514000@Atlassian.JIRA>
References: <JIRA.12583814.1441283514000@Atlassian.JIRA>
	<JIRA.12583814.1441283514000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583814.1441283514000.968.1441291920684@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-952:
-----------------------------------------

Probably worth noting checkNotNullParan returns the value checked so the use of this method can be inlined.

> Use WildFly Common for null param checks
> ----------------------------------------
>
>                 Key: WFCORE-952
>                 URL: https://issues.jboss.org/browse/WFCORE-952
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: David Lloyd
>            Priority: Minor
>             Fix For: 3.0.0.Alpha1
>
>
> For each module, do the following:
> * Locate any/all null param check methods in the log msg
> * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
> * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 11:02:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 3 Sep 2015 11:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5071) Refactor
 org.jboss.as.jpa.transaction.TransactionUtil to not use static globals,
 use the JPAService singleton instead
In-Reply-To: <JIRA.12580673.1438963369000@Atlassian.JIRA>
References: <JIRA.12580673.1438963369000@Atlassian.JIRA>
	<JIRA.12580673.1438963369000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580673.1438963369000.1001.1441292520227@Atlassian.JIRA>


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

Scott Marlow reassigned WFLY-5071:
----------------------------------

    Assignee: Stuart Douglas  (was: Scott Marlow)


> Refactor org.jboss.as.jpa.transaction.TransactionUtil to not use static globals, use the JPAService singleton instead
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5071
>                 URL: https://issues.jboss.org/browse/WFLY-5071
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> Perhaps something like the following in TransactionUtil:
> {code}
>    public static TransactionManager getTransactionManager() {
>      JPAService jpaService = 
> currentServiceContainer().getService(org.jboss.as.jpa.service.JPAService.SERVICE_NAME);
>    return jpaService.getTransactionManager();
>    }
>     private static ServiceContainer currentServiceContainer() {
>         if(System.getSecurityManager() == null) {
>             return CurrentServiceContainer.getServiceContainer();
>         }
>         return AccessController.doPrivileged(CurrentServiceContainer.GET_ACTION);
>     }
> {code}
> Might want to refactor the callers into TransactionUtil to cache the JPAService, so we don't have to look it up several times per entity manager invocation.  Otherwise, the service lookup may be done too many times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 11:02:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 3 Sep 2015 11:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5071) Refactor
 org.jboss.as.jpa.transaction.TransactionUtil to not use static globals,
 use the JPAService singleton instead
In-Reply-To: <JIRA.12580673.1438963369000@Atlassian.JIRA>
References: <JIRA.12580673.1438963369000@Atlassian.JIRA>
	<JIRA.12580673.1438963369000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580673.1438963369000.1005.1441292520349@Atlassian.JIRA>


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

Scott Marlow closed WFLY-5071.
------------------------------
    Resolution: Done


> Refactor org.jboss.as.jpa.transaction.TransactionUtil to not use static globals, use the JPAService singleton instead
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5071
>                 URL: https://issues.jboss.org/browse/WFLY-5071
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> Perhaps something like the following in TransactionUtil:
> {code}
>    public static TransactionManager getTransactionManager() {
>      JPAService jpaService = 
> currentServiceContainer().getService(org.jboss.as.jpa.service.JPAService.SERVICE_NAME);
>    return jpaService.getTransactionManager();
>    }
>     private static ServiceContainer currentServiceContainer() {
>         if(System.getSecurityManager() == null) {
>             return CurrentServiceContainer.getServiceContainer();
>         }
>         return AccessController.doPrivileged(CurrentServiceContainer.GET_ACTION);
>     }
> {code}
> Might want to refactor the callers into TransactionUtil to cache the JPAService, so we don't have to look it up several times per entity manager invocation.  Otherwise, the service lookup may be done too many times.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 11:08:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 11:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-955) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.1027.1441292880193@Atlassian.JIRA>


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

Kabir Khan moved WFLY-5225 to WFCORE-955:
-----------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-955  (was: WFLY-5225)
          Component/s: Domain Management
                           (was: CLI)
    Affects Version/s: 2.0.0.Beta5
                           (was: 10.0.0.Beta2)


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-955
>                 URL: https://issues.jboss.org/browse/WFCORE-955
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 11:08:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 11:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-955) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.1031.1441292880328@Atlassian.JIRA>


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

Kabir Khan updated WFCORE-955:
------------------------------
    Fix Version/s: 2.0.0.CR1


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-955
>                 URL: https://issues.jboss.org/browse/WFCORE-955
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 11:09:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 11:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-954) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583843.1441290607000@Atlassian.JIRA>
References: <JIRA.12583843.1441290607000@Atlassian.JIRA>
	<JIRA.12583843.1441290607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583843.1441290607000.1040.1441292940549@Atlassian.JIRA>


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

Kabir Khan closed WFCORE-954.
-----------------------------
    Resolution: Duplicate Issue


Duplicate of WFCORE-955

> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-954
>                 URL: https://issues.jboss.org/browse/WFCORE-954
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> This is a clone of WFLY-5225 to make sure that if the fix is in core, that we track it with this one.
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 11:22:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 11:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-955) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.1147.1441293720281@Atlassian.JIRA>


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

Kabir Khan reassigned WFCORE-955:
---------------------------------

    Assignee: Brian Stansberry  (was: Kabir Khan)


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-955
>                 URL: https://issues.jboss.org/browse/WFCORE-955
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 11:23:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-955) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.1158.1441293780362@Atlassian.JIRA>


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

Kabir Khan commented on WFCORE-955:
-----------------------------------

[~brian.stansberry] Take https://github.com/wildfly/wildfly-core/compare/wildfly:master...kabir:WFLY-5225?expand=1 as my issue, and use the domain.xml above with all servers removed from host.xml.

The issue is that the undertow adds the capability profile=default/org.wildfly.undertow.listener.default which depends on org.wildfly.network.socket-binding.http, which is a ProfileChildCapabilityScope. n the loop in CapabilityRegistry.resolveCapabilities() it calls findSatisfactoryCapability() which returns a SatisfactoryCapability with a multipleCapabilities with size 1, and the only entry is now a SocketBindingGroupChildScope. Since the SatisfactoryCapability.multipleCapabilities != null it ends up calling dependentContest.getIncludingScopes() (the dependentContext is of type ProfileChildCapabilityScope), and so when it reaches storeIncludes() called with key='new' it blows up  since there is no 'nonsense' profile.

In core on its own this does not happen since there is no undertow causing this behaviour. 


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-955
>                 URL: https://issues.jboss.org/browse/WFCORE-955
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 11:25:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 11:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-955) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.1169.1441293900412@Atlassian.JIRA>


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

Kabir Khan edited comment on WFCORE-955 at 9/3/15 11:24 AM:
------------------------------------------------------------

[~brian.stansberry] Take https://github.com/wildfly/wildfly-core/compare/wildfly:master...kabir:WFLY-5225?expand=1 as my issue, and use the domain.xml above with all servers removed from host.xml.

The issue is that the undertow adds the capability profile=default/org.wildfly.undertow.listener.default which depends on org.wildfly.network.socket-binding.http, which is a ProfileChildCapabilityScope. n the loop in CapabilityRegistry.resolveCapabilities() it calls findSatisfactoryCapability() which returns a SatisfactoryCapability with a multipleCapabilities with size 1, and the only entry is now a SocketBindingGroupChildScope. Since the SatisfactoryCapability.multipleCapabilities != null it ends up calling dependentContest.getIncludingScopes() (the dependentContext is of type ProfileChildCapabilityScope), and so when it reaches storeIncludes() called with key='new' it blows up  since there is no 'nonsense' profile.

There also might be a slight race condition since if I don't debug I always get the NPE, and if I debug really slowly I think I have seen it give the 'proper' error message instead.
In core on its own this does not happen since there is no undertow causing this behaviour. 



was (Author: kabirkhan):
[~brian.stansberry] Take https://github.com/wildfly/wildfly-core/compare/wildfly:master...kabir:WFLY-5225?expand=1 as my issue, and use the domain.xml above with all servers removed from host.xml.

The issue is that the undertow adds the capability profile=default/org.wildfly.undertow.listener.default which depends on org.wildfly.network.socket-binding.http, which is a ProfileChildCapabilityScope. n the loop in CapabilityRegistry.resolveCapabilities() it calls findSatisfactoryCapability() which returns a SatisfactoryCapability with a multipleCapabilities with size 1, and the only entry is now a SocketBindingGroupChildScope. Since the SatisfactoryCapability.multipleCapabilities != null it ends up calling dependentContest.getIncludingScopes() (the dependentContext is of type ProfileChildCapabilityScope), and so when it reaches storeIncludes() called with key='new' it blows up  since there is no 'nonsense' profile.

In core on its own this does not happen since there is no undertow causing this behaviour. 


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-955
>                 URL: https://issues.jboss.org/browse/WFCORE-955
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 11:25:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 3 Sep 2015 11:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-955) Server is not responding
 after attempt to set parent of profile to non-existent profile
In-Reply-To: <JIRA.12583029.1440686047000@Atlassian.JIRA>
References: <JIRA.12583029.1440686047000@Atlassian.JIRA>
	<JIRA.12583029.1440686047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583029.1440686047000.1174.1441293900571@Atlassian.JIRA>


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

Kabir Khan edited comment on WFCORE-955 at 9/3/15 11:24 AM:
------------------------------------------------------------

[~brian.stansberry] Take https://github.com/wildfly/wildfly-core/compare/wildfly:master...kabir:WFLY-5225?expand=1 as my issue, and use the domain.xml above with all servers removed from host.xml.

The issue is that the undertow adds the capability profile=default/org.wildfly.undertow.listener.default which depends on org.wildfly.network.socket-binding.http, which is a ProfileChildCapabilityScope. n the loop in CapabilityRegistry.resolveCapabilities() it calls findSatisfactoryCapability() which returns a SatisfactoryCapability with a multipleCapabilities with size 1, and the only entry is now a SocketBindingGroupChildScope. Since the SatisfactoryCapability.multipleCapabilities != null it ends up calling dependentContest.getIncludingScopes() (the dependentContext is of type ProfileChildCapabilityScope), and so when it reaches storeIncludes() called with key='new' it blows up  since there is no 'nonsense' profile.

There also might be a slight race condition since if I don't debug I always get the NPE, and if I debug really slowly I think I have seen it give the 'proper' error message instead.

In core on its own this does not happen since there is no undertow causing this behaviour. 



was (Author: kabirkhan):
[~brian.stansberry] Take https://github.com/wildfly/wildfly-core/compare/wildfly:master...kabir:WFLY-5225?expand=1 as my issue, and use the domain.xml above with all servers removed from host.xml.

The issue is that the undertow adds the capability profile=default/org.wildfly.undertow.listener.default which depends on org.wildfly.network.socket-binding.http, which is a ProfileChildCapabilityScope. n the loop in CapabilityRegistry.resolveCapabilities() it calls findSatisfactoryCapability() which returns a SatisfactoryCapability with a multipleCapabilities with size 1, and the only entry is now a SocketBindingGroupChildScope. Since the SatisfactoryCapability.multipleCapabilities != null it ends up calling dependentContest.getIncludingScopes() (the dependentContext is of type ProfileChildCapabilityScope), and so when it reaches storeIncludes() called with key='new' it blows up  since there is no 'nonsense' profile.

There also might be a slight race condition since if I don't debug I always get the NPE, and if I debug really slowly I think I have seen it give the 'proper' error message instead.
In core on its own this does not happen since there is no undertow causing this behaviour. 


> Server is not responding after attempt to set parent of profile to non-existent profile
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-955
>                 URL: https://issues.jboss.org/browse/WFCORE-955
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Marek Kopeck?
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> *Description of problem:*
> Server is not responding after attempt to set parent of profile to non-existent profile. 
> Server is not responding also after attempt to set parent of socket-binding-group to non-existent socket-binding-group.
> This works correctly on wildfly-core (2.0.0.Beta4). But this occurs on wildfly (master branch) and on EAP 7.0.0.DR9. It may be some integration issue.
> Priority of this jira tends to be critical.
> *How reproducible:*
> Always
> *Steps to Reproduce (profile):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /profile=new:write-attribute(name=includes,value=\[nonsence\])
> ## /profile=new:remove
> *Actual results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.NullPointerException:null"
> }
> [domain at localhost:9990 /] /profile=new:remove
> {noformat}
> * server needs to be restarted
> *Expected results:*
> {noformat}
> [domain at localhost:9990 /] /profile=new:write-attribute(name=includes,value=[nonsence])
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.profile.nonsence in context 'profiles'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /] /profile=new:remove
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> {noformat}
> *Steps to reproduce (socket-binding-group):*
> # Get fresh EAP
> # ./domain.sh
> # ./jboss-cli.sh
> ## /profile=new:add()
> ## /socket-binding-group=testt:add(default-interface=public,includes=\[nonsence\])
> ## /profile=new:remove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 12:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 3 Sep 2015 12:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-946) CLI Hangs in 'quit'
In-Reply-To: <JIRA.12583585.1441202553000@Atlassian.JIRA>
References: <JIRA.12583585.1441202553000@Atlassian.JIRA>
	<JIRA.12583585.1441202553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583585.1441202553000.1635.1441298400228@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-946:
-----------------------------------------

[~gonthim] Follow up to the discussion earlier: I confirmed that hitting another key results in the process exiting.

> CLI Hangs in 'quit'
> -------------------
>
>                 Key: WFCORE-946
>                 URL: https://issues.jboss.org/browse/WFCORE-946
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Joe Wertz
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>         Attachments: quit-hang.txt
>
>
> If you enter the 'quit' command, the CLI hangs.
> I'll attach a thread dump.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 12:50:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 3 Sep 2015 12:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-896) Cannot patch EAP once Docs
 are excluded from installation
In-Reply-To: <JIRA.12581971.1440069884000@Atlassian.JIRA>
References: <JIRA.12581971.1440069884000@Atlassian.JIRA>
	<JIRA.12581971.1440069884000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581971.1440069884000.1675.1441299000310@Atlassian.JIRA>


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

Alexey Loubyansky commented on WFCORE-896:
------------------------------------------

With the referenced PR merged, misc content modifications now have an additional attribute called condition. If the attribute is not present then the modification is considered to be required and the patch will be aborted if the modification could not be applied for some reason.
If the modification attribute is present then at application patch the condition will be evaluated and if the condition is satisfied, the modification will be applied, otherwise the modification will simply be skipped w/o aborting the whole patch.
This fix introduced a new patch.xml schema include the new attribute. And the patchgen tool (not tracked here) was also updated to support the generation of patch.xml files that may contain conditions.
The only condition added is the one checking for existence of a file system path relative to the installation root directory.

> Cannot patch EAP once Docs are excluded from installation
> ---------------------------------------------------------
>
>                 Key: WFCORE-896
>                 URL: https://issues.jboss.org/browse/WFCORE-896
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Patching 
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Alexey Loubyansky
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>         Attachments: dr8_to_dr8x.zip
>
>
> EAP installer allows user to exclude some packs from installation. Docs directory is one of them. If user choose to do so, $JBOSS_HOME/docs directory is not present in distribution.
> Trying to apply a patch (contains changes with docs files) on such a distribution gives me:
> {noformat}
> java.io.FileNotFoundException: /home/pkremens/workspace/jboss-eap-7.0/docs/schema/saml-schema-authn-context-xmldsig-2.0.xsd (No such file or directory)
> {noformat}
> This could block customers, who are using installer to get EAP, from consuming the patches for CP releases in future.
> Patch was generated using:
> https://github.com/jbossas/patch-gen
> dr8_to_dr8x.zip patch.xml:
> {code:xml}
> <?xml version="1.0" ?>
> <patch xmlns="urn:jboss:patch:1.0" id="dr8_to_dr8x">
>     <description>
>         No description available
>     </description>
>     <upgrade name="EAP" version="7.0.0.Alpha1" to-version="7.0.0.Alpha1"/>
>     <element id="layer-base-dr8_to_dr8x">
>         <description>
>             No description available
>         </description>
>         <upgrade name="base"/>
>     </element>
>     <misc-files>
>         <added path="docs/schema/saml-schema-authn-context-xmldsig-2.1.xsd" hash="25d2e47a02d248101af86cff07daf9d51d8da379"/>
>         <updated path="docs/schema/saml-schema-ecp-2.0.xsd" hash="97984434c30816939c0f64b9388dc75d977a3b17" new-hash="fa7e234444b3c5d9ede81b4799dfaff8632d987a"/>
>         <removed path="docs/schema/saml-schema-authn-context-xmldsig-2.0.xsd" hash="25d2e47a02d248101af86cff07daf9d51d8da379"/>
>     </misc-files>
> </patch>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 13:34:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 13:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-285) Restore the package
 'org.wildfly.security.permission'
In-Reply-To: <JIRA.12583873.1441301621000@Atlassian.JIRA>
References: <JIRA.12583873.1441301621000@Atlassian.JIRA>
	<JIRA.12583873.1441301621522@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583873.1441301621000.1825.1441301640128@Atlassian.JIRA>

Darran Lofthouse created ELY-285:
------------------------------------

             Summary: Restore the package 'org.wildfly.security.permission'
                 Key: ELY-285
                 URL: https://issues.jboss.org/browse/ELY-285
             Project: WildFly Elytron
          Issue Type: Task
          Components: Security Manager
    Affects Versions: 1.0.0.CR1
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.0.0.Final






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 13:43:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 13:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-285) Restore the package
 'org.wildfly.security.permission'
In-Reply-To: <JIRA.12583873.1441301621000@Atlassian.JIRA>
References: <JIRA.12583873.1441301621000@Atlassian.JIRA>
	<JIRA.12583873.1441301621000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583873.1441301621000.1834.1441302180155@Atlassian.JIRA>


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

Darran Lofthouse resolved ELY-285.
----------------------------------
    Resolution: Done


> Restore the package 'org.wildfly.security.permission'
> -----------------------------------------------------
>
>                 Key: ELY-285
>                 URL: https://issues.jboss.org/browse/ELY-285
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Security Manager
>    Affects Versions: 1.0.0.CR1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 14:23:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 14:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-277) Release WildFly Elytron
	1.0.0.Final
In-Reply-To: <JIRA.12582042.1440085886000@Atlassian.JIRA>
References: <JIRA.12582042.1440085886000@Atlassian.JIRA>
	<JIRA.12582042.1440085886000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582042.1440085886000.1937.1441304580183@Atlassian.JIRA>


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

Darran Lofthouse resolved ELY-277.
----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.0.0.Final
> -----------------------------------
>
>                 Key: ELY-277
>                 URL: https://issues.jboss.org/browse/ELY-277
>             Project: WildFly Elytron
>          Issue Type: Release
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 14:32:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 14:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-610) Integrate Elytron for
 management security.
In-Reply-To: <JIRA.12566595.1427107186000@Atlassian.JIRA>
References: <JIRA.12566595.1427107186000@Atlassian.JIRA>
	<JIRA.12566595.1427107186000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566595.1427107186000.1969.1441305120339@Atlassian.JIRA>


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

Darran Lofthouse updated WFCORE-610:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 3.0.0.Beta1)


> Integrate Elytron for management security.
> ------------------------------------------
>
>                 Key: WFCORE-610
>                 URL: https://issues.jboss.org/browse/WFCORE-610
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha1
>
>
> This is a top level container task for the integration of Elytron for domain management security.
> Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration.
> At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)).  However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server.
> Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:00:00 2015
From: issues at jboss.org (Manuel Colchete (JIRA))
Date: Thu, 3 Sep 2015 15:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener
 request client certificate despite verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.2010.1441306800305@Atlassian.JIRA>


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

Manuel Colchete updated WFLY-5256:
----------------------------------
    Description: 
HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access secured resource as first, it don't requested certificate and return HTTP status 403.


  was:
HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED)




> HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5256
>                 URL: https://issues.jboss.org/browse/WFLY-5256
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Manuel Colchete
>            Assignee: Stuart Douglas
>
> HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access secured resource as first, it don't requested certificate and return HTTP status 403.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:09:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 15:09:00 -0400 (EDT)
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.1441307301220@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583890.1441307301000.2035.1441307340339@Atlassian.JIRA>

Darran Lofthouse created ELY-286:
------------------------------------

             Summary: HTTP Digest Authentication
                 Key: ELY-286
                 URL: https://issues.jboss.org/browse/ELY-286
             Project: WildFly Elytron
          Issue Type: Sub-task
          Components: HTTP
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:10:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 15:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-284) Upgrade to WildFly Common
	1.0.0.Final
In-Reply-To: <JIRA.12583681.1441274996000@Atlassian.JIRA>
References: <JIRA.12583681.1441274996000@Atlassian.JIRA>
	<JIRA.12583681.1441274996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583681.1441274996000.2042.1441307400247@Atlassian.JIRA>


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

Darran Lofthouse resolved ELY-284.
----------------------------------
    Resolution: Done


> Upgrade to WildFly Common 1.0.0.Final
> -------------------------------------
>
>                 Key: ELY-284
>                 URL: https://issues.jboss.org/browse/ELY-284
>             Project: WildFly Elytron
>          Issue Type: Component  Upgrade
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1, 1.0.0.Final
>
>
> Tagged as critical as trying to avoid tagging WildFly Elytron 1.0.0.Final with an Alpha dependency,



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:37:00 2015
From: issues at jboss.org (carl zhang (JIRA))
Date: Thu, 3 Sep 2015 15:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5269) jsf-impl-2.2.8-jbossorg-1.jar
 is not in default Runtime library list of WildFly 8.2.0
In-Reply-To: <JIRA.12583897.1441308975000@Atlassian.JIRA>
References: <JIRA.12583897.1441308975000@Atlassian.JIRA>
	<JIRA.12583897.1441308975687@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583897.1441308975000.2122.1441309020168@Atlassian.JIRA>

carl zhang created WFLY-5269:
--------------------------------

             Summary: jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime library list of WildFly 8.2.0
                 Key: WFLY-5269
                 URL: https://issues.jboss.org/browse/WFLY-5269
             Project: WildFly
          Issue Type: Feature Request
          Components: Class Loading
    Affects Versions: 8.2.0.Final
            Reporter: carl zhang
            Assignee: David Lloyd
            Priority: Minor


In Eclipse, I chose WildFly 8.2.0 server as my local web server. Then I created Dynamic Web Project. After done, I check the project Libraries-->WildFly 8.x Runtime libraries. I can see jboss-jsf-api_2.2_spec-2.2.8.jar in the list, but cannot see jsf-impl-2.2.8-jbossorg-1.jar

So my Java codes related to jsf-impl classes cannot pass the compile. And I cannot manually add jsf-impl.jar into the project WEB_INF/lib because it cause deployment conflict.

Please add the jsf-impl jar file into default Runtime library list. I don't check 9.0.0 and 10.0.0, if it is not in their default list. Please add it in



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:37:00 2015
From: issues at jboss.org (carl zhang (JIRA))
Date: Thu, 3 Sep 2015 15:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5270) jsf-impl-2.2.8-jbossorg-1.jar
 is not in default Runtime library list of WildFly 8.2.0
In-Reply-To: <JIRA.12583898.1441308986000@Atlassian.JIRA>
References: <JIRA.12583898.1441308986000@Atlassian.JIRA>
	<JIRA.12583898.1441308986871@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583898.1441308986000.2125.1441309020346@Atlassian.JIRA>

carl zhang created WFLY-5270:
--------------------------------

             Summary: jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime library list of WildFly 8.2.0
                 Key: WFLY-5270
                 URL: https://issues.jboss.org/browse/WFLY-5270
             Project: WildFly
          Issue Type: Feature Request
          Components: Class Loading
    Affects Versions: 8.2.0.Final
            Reporter: carl zhang
            Assignee: David Lloyd
            Priority: Minor


In Eclipse, I chose WildFly 8.2.0 server as my local web server. Then I created Dynamic Web Project. After done, I check the project Libraries-->WildFly 8.x Runtime libraries. I can see jboss-jsf-api_2.2_spec-2.2.8.jar in the list, but cannot see jsf-impl-2.2.8-jbossorg-1.jar

So my Java codes related to jsf-impl classes cannot pass the compile. And I cannot manually add jsf-impl.jar into the project WEB_INF/lib because it cause deployment conflict.

Please add the jsf-impl jar file into default Runtime library list. I don't check 9.0.0 and 10.0.0, if it is not in their default list. Please add it in



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:37:00 2015
From: issues at jboss.org (carl zhang (JIRA))
Date: Thu, 3 Sep 2015 15:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5271) jsf-impl-2.2.8-jbossorg-1.jar
 is not in default Runtime library list of WildFly 8.2.0
In-Reply-To: <JIRA.12583899.1441309000000@Atlassian.JIRA>
References: <JIRA.12583899.1441309000000@Atlassian.JIRA>
	<JIRA.12583899.1441309000662@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583899.1441309000000.2128.1441309020397@Atlassian.JIRA>

carl zhang created WFLY-5271:
--------------------------------

             Summary: jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime library list of WildFly 8.2.0
                 Key: WFLY-5271
                 URL: https://issues.jboss.org/browse/WFLY-5271
             Project: WildFly
          Issue Type: Feature Request
          Components: Class Loading
    Affects Versions: 8.2.0.Final
            Reporter: carl zhang
            Assignee: David Lloyd
            Priority: Minor


In Eclipse, I chose WildFly 8.2.0 server as my local web server. Then I created Dynamic Web Project. After done, I check the project Libraries-->WildFly 8.x Runtime libraries. I can see jboss-jsf-api_2.2_spec-2.2.8.jar in the list, but cannot see jsf-impl-2.2.8-jbossorg-1.jar

So my Java codes related to jsf-impl classes cannot pass the compile. And I cannot manually add jsf-impl.jar into the project WEB_INF/lib because it cause deployment conflict.

Please add the jsf-impl jar file into default Runtime library list. I don't check 9.0.0 and 10.0.0, if it is not in their default list. Please add it in



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:38:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Sep 2015 15:38:00 -0400 (EDT)
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.2131.1441309080100@Atlassian.JIRA>


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

Darran Lofthouse updated ELY-286:
---------------------------------
    Description: 
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/]


> HTTP Digest Authentication
> --------------------------
>
>                 Key: ELY-286
>                 URL: https://issues.jboss.org/browse/ELY-286
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha1
>
>
> 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/]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:41:00 2015
From: issues at jboss.org (carl zhang (JIRA))
Date: Thu, 3 Sep 2015 15:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5272) WildFly:
 jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime list
In-Reply-To: <JIRA.12583900.1441309249000@Atlassian.JIRA>
References: <JIRA.12583900.1441309249000@Atlassian.JIRA>
	<JIRA.12583900.1441309249529@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583900.1441309249000.2137.1441309260186@Atlassian.JIRA>

carl zhang created WFLY-5272:
--------------------------------

             Summary: WildFly: jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime list
                 Key: WFLY-5272
                 URL: https://issues.jboss.org/browse/WFLY-5272
             Project: WildFly
          Issue Type: Feature Request
          Components: Server
    Affects Versions: 8.2.0.Final
            Reporter: carl zhang
            Assignee: Jason Greene
            Priority: Minor


In Eclipse, I chose WildFly 8.2.0 server as my local web server. Then I created Dynamic Web Project. After done, I check the project Libraries-->WildFly 8.x Runtime libraries. I can see jboss-jsf-api_2.2_spec-2.2.8.jar in the list, but cannot see jsf-impl-2.2.8-jbossorg-1.jar

So my Java codes related to jsf-impl classes cannot pass the compile. And I cannot manually add jsf-impl.jar into the project WEB_INF/lib because it cause deployment conflict.

Please add the jsf-impl jar file into default Runtime library list. I don't check 9.0.0 and 10.0.0, if it is not in their default list. Please add it in



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 15:47:00 2015
From: issues at jboss.org (carl zhang (JIRA))
Date: Thu, 3 Sep 2015 15:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5271) jsf-impl-2.2.8-jbossorg-1.jar
 is not in default Runtime library list of WildFly 8.2.0
In-Reply-To: <JIRA.12583899.1441309000000@Atlassian.JIRA>
References: <JIRA.12583899.1441309000000@Atlassian.JIRA>
	<JIRA.12583899.1441309000000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583899.1441309000000.2152.1441309620299@Atlassian.JIRA>


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

carl zhang commented on WFLY-5271:
----------------------------------

Duplicate with WFLY-5271

> jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime library list of WildFly 8.2.0
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-5271
>                 URL: https://issues.jboss.org/browse/WFLY-5271
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Class Loading
>    Affects Versions: 8.2.0.Final
>            Reporter: carl zhang
>            Assignee: David Lloyd
>            Priority: Minor
>
> In Eclipse, I chose WildFly 8.2.0 server as my local web server. Then I created Dynamic Web Project. After done, I check the project Libraries-->WildFly 8.x Runtime libraries. I can see jboss-jsf-api_2.2_spec-2.2.8.jar in the list, but cannot see jsf-impl-2.2.8-jbossorg-1.jar
> So my Java codes related to jsf-impl classes cannot pass the compile. And I cannot manually add jsf-impl.jar into the project WEB_INF/lib because it cause deployment conflict.
> Please add the jsf-impl jar file into default Runtime library list. I don't check 9.0.0 and 10.0.0, if it is not in their default list. Please add it in



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 16:16:00 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 3 Sep 2015 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5273) [GSS] (6.4.z) EJB IOR
 contains wrong port (non-SSL port) information when SSL is required
In-Reply-To: <JIRA.12583907.1441311333000@Atlassian.JIRA>
References: <JIRA.12583907.1441311333000@Atlassian.JIRA>
	<JIRA.12583907.1441311333529@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583907.1441311333000.2183.1441311360885@Atlassian.JIRA>

Derek Horton created WFLY-5273:
----------------------------------

             Summary: [GSS] (6.4.z) EJB IOR contains wrong port (non-SSL port) information when SSL is required
                 Key: WFLY-5273
                 URL: https://issues.jboss.org/browse/WFLY-5273
             Project: WildFly
          Issue Type: Bug
            Reporter: Derek Horton
            Assignee: Jason Greene


Description of problem:

- Configure JBoss to only allow IIOP connections over SSL
- It is possible to do this, but the configuration is confusing (possibly a bug)

Details of the setup/issue:

- When enabling SSL for jacorb, it normally listens on both the non-ssl port and the ssl port
- Setting server-requires="ServerAuth" causes the server to stop listening on non-ssl port
- However, the IOR tells client to connect to non-ssl port ...even though its not listening on it

        String lookup = "corbaname:iiop:" + host + ":" + port +"#" + ejbLookupPath;

        // lookup the IIOP EJB
        Object iiopObj = ctx.lookup(lookup);

        // the call to the EJB will fail due to the port being wrong non-ssl vs ssl

- The workaround is to use the following ior-setting to correct the port settings in the IOR

  /subsystem=jacorb/ior-settings=default/setting=transport-config:add(confidentiality=required)

- Shouldn't setting "server-requires=ServerAuth" change the port info in the IOR?




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 16:16:01 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 3 Sep 2015 16:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5274) [GSS] (6.4.z) EJB IOR
 contains wrong port (non-SSL port) information when SSL is required
In-Reply-To: <JIRA.12583908.1441311342000@Atlassian.JIRA>
References: <JIRA.12583908.1441311342000@Atlassian.JIRA>
	<JIRA.12583908.1441311342432@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583908.1441311342000.2188.1441311361015@Atlassian.JIRA>

Derek Horton created WFLY-5274:
----------------------------------

             Summary: [GSS] (6.4.z) EJB IOR contains wrong port (non-SSL port) information when SSL is required
                 Key: WFLY-5274
                 URL: https://issues.jboss.org/browse/WFLY-5274
             Project: WildFly
          Issue Type: Bug
            Reporter: Derek Horton
            Assignee: Jason Greene


Description of problem:

- Configure JBoss to only allow IIOP connections over SSL
- It is possible to do this, but the configuration is confusing (possibly a bug)

Details of the setup/issue:

- When enabling SSL for jacorb, it normally listens on both the non-ssl port and the ssl port
- Setting server-requires="ServerAuth" causes the server to stop listening on non-ssl port
- However, the IOR tells client to connect to non-ssl port ...even though its not listening on it

        String lookup = "corbaname:iiop:" + host + ":" + port +"#" + ejbLookupPath;

        // lookup the IIOP EJB
        Object iiopObj = ctx.lookup(lookup);

        // the call to the EJB will fail due to the port being wrong non-ssl vs ssl

- The workaround is to use the following ior-setting to correct the port settings in the IOR

  /subsystem=jacorb/ior-settings=default/setting=transport-config:add(confidentiality=required)

- Shouldn't setting "server-requires=ServerAuth" change the port info in the IOR?




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 16:18:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Sep 2015 16:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5274) [GSS] (6.4.z) EJB IOR
 contains wrong port (non-SSL port) information when SSL is required
In-Reply-To: <JIRA.12583908.1441311342000@Atlassian.JIRA>
References: <JIRA.12583908.1441311342000@Atlassian.JIRA>
	<JIRA.12583908.1441311342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583908.1441311342000.2192.1441311480195@Atlassian.JIRA>


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

RH Bugzilla Integration updated WFLY-5274:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1259902
        Bugzilla Update: Perform


> [GSS] (6.4.z) EJB IOR contains wrong port (non-SSL port) information when SSL is required
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5274
>                 URL: https://issues.jboss.org/browse/WFLY-5274
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Derek Horton
>            Assignee: Jason Greene
>
> Description of problem:
> - Configure JBoss to only allow IIOP connections over SSL
> - It is possible to do this, but the configuration is confusing (possibly a bug)
> Details of the setup/issue:
> - When enabling SSL for jacorb, it normally listens on both the non-ssl port and the ssl port
> - Setting server-requires="ServerAuth" causes the server to stop listening on non-ssl port
> - However, the IOR tells client to connect to non-ssl port ...even though its not listening on it
>         String lookup = "corbaname:iiop:" + host + ":" + port +"#" + ejbLookupPath;
>         // lookup the IIOP EJB
>         Object iiopObj = ctx.lookup(lookup);
>         // the call to the EJB will fail due to the port being wrong non-ssl vs ssl
> - The workaround is to use the following ior-setting to correct the port settings in the IOR
>   /subsystem=jacorb/ior-settings=default/setting=transport-config:add(confidentiality=required)
> - Shouldn't setting "server-requires=ServerAuth" change the port info in the IOR?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 16:18:00 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 3 Sep 2015 16:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5274) EJB IOR contains wrong port
 (non-SSL port) information when SSL is required
In-Reply-To: <JIRA.12583908.1441311342000@Atlassian.JIRA>
References: <JIRA.12583908.1441311342000@Atlassian.JIRA>
	<JIRA.12583908.1441311342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583908.1441311342000.2195.1441311480275@Atlassian.JIRA>


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

Derek Horton updated WFLY-5274:
-------------------------------
    Summary: EJB IOR contains wrong port (non-SSL port) information when SSL is required  (was: [GSS] (6.4.z) EJB IOR contains wrong port (non-SSL port) information when SSL is required)


> EJB IOR contains wrong port (non-SSL port) information when SSL is required
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5274
>                 URL: https://issues.jboss.org/browse/WFLY-5274
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Derek Horton
>            Assignee: Jason Greene
>
> Description of problem:
> - Configure JBoss to only allow IIOP connections over SSL
> - It is possible to do this, but the configuration is confusing (possibly a bug)
> Details of the setup/issue:
> - When enabling SSL for jacorb, it normally listens on both the non-ssl port and the ssl port
> - Setting server-requires="ServerAuth" causes the server to stop listening on non-ssl port
> - However, the IOR tells client to connect to non-ssl port ...even though its not listening on it
>         String lookup = "corbaname:iiop:" + host + ":" + port +"#" + ejbLookupPath;
>         // lookup the IIOP EJB
>         Object iiopObj = ctx.lookup(lookup);
>         // the call to the EJB will fail due to the port being wrong non-ssl vs ssl
> - The workaround is to use the following ior-setting to correct the port settings in the IOR
>   /subsystem=jacorb/ior-settings=default/setting=transport-config:add(confidentiality=required)
> - Shouldn't setting "server-requires=ServerAuth" change the port info in the IOR?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 16:34:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 3 Sep 2015 16:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5269) jsf-impl-2.2.8-jbossorg-1.jar
 is not in default Runtime library list of WildFly 8.2.0
In-Reply-To: <JIRA.12583897.1441308975000@Atlassian.JIRA>
References: <JIRA.12583897.1441308975000@Atlassian.JIRA>
	<JIRA.12583897.1441308975000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583897.1441308975000.2200.1441312440168@Atlassian.JIRA>


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

David Lloyd deleted WFLY-5269:
------------------------------


> jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime library list of WildFly 8.2.0
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-5269
>                 URL: https://issues.jboss.org/browse/WFLY-5269
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: carl zhang
>            Assignee: David Lloyd
>            Priority: Minor
>
> In Eclipse, I chose WildFly 8.2.0 server as my local web server. Then I created Dynamic Web Project. After done, I check the project Libraries-->WildFly 8.x Runtime libraries. I can see jboss-jsf-api_2.2_spec-2.2.8.jar in the list, but cannot see jsf-impl-2.2.8-jbossorg-1.jar
> So my Java codes related to jsf-impl classes cannot pass the compile. And I cannot manually add jsf-impl.jar into the project WEB_INF/lib because it cause deployment conflict.
> Please add the jsf-impl jar file into default Runtime library list. I don't check 9.0.0 and 10.0.0, if it is not in their default list. Please add it in



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 16:34:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 3 Sep 2015 16:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5270) jsf-impl-2.2.8-jbossorg-1.jar
 is not in default Runtime library list of WildFly 8.2.0
In-Reply-To: <JIRA.12583898.1441308986000@Atlassian.JIRA>
References: <JIRA.12583898.1441308986000@Atlassian.JIRA>
	<JIRA.12583898.1441308986000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583898.1441308986000.2204.1441312440250@Atlassian.JIRA>


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

David Lloyd deleted WFLY-5270:
------------------------------


> jsf-impl-2.2.8-jbossorg-1.jar is not in default Runtime library list of WildFly 8.2.0
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-5270
>                 URL: https://issues.jboss.org/browse/WFLY-5270
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: carl zhang
>            Assignee: David Lloyd
>            Priority: Minor
>
> In Eclipse, I chose WildFly 8.2.0 server as my local web server. Then I created Dynamic Web Project. After done, I check the project Libraries-->WildFly 8.x Runtime libraries. I can see jboss-jsf-api_2.2_spec-2.2.8.jar in the list, but cannot see jsf-impl-2.2.8-jbossorg-1.jar
> So my Java codes related to jsf-impl classes cannot pass the compile. And I cannot manually add jsf-impl.jar into the project WEB_INF/lib because it cause deployment conflict.
> Please add the jsf-impl jar file into default Runtime library list. I don't check 9.0.0 and 10.0.0, if it is not in their default list. Please add it in



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 16:50:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 3 Sep 2015 16:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.2236.1441313400281@Atlassian.JIRA>


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

Edson Tirelli commented on DROOLS-880:
--------------------------------------

I am looking into it, and it will be fixed before we release 6.3.0.Final in a couple weeks. Please give us a few more days to investigate.

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 17:10:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 3 Sep 2015 17:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.2263.1441314600212@Atlassian.JIRA>


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

Edson Tirelli commented on DROOLS-880:
--------------------------------------

I think I was able to reproduce the problem. In version 6.3.x, in order to support both XML formats (XStream and JAXB), we had to add a new header to the HTTP request:

X-KIE-ContentType

It can be assigned one of the following values: xstream, xml, json

If I add that header to the HTTP request, it works fine (see attached screenshot). When I execute that request, it prints on my console:

17:04:45,715 INFO  [stdout] (default task-18) >>>>> TestVO = "MyVO1"

Please try adding that header and let me know if it works for you. Also, we released 6.3.0.CR2 a couple days ago. Please upgrade to that version.




> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 17:11:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 3 Sep 2015 17:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.2267.1441314660143@Atlassian.JIRA>


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

Edson Tirelli updated DROOLS-880:
---------------------------------
    Attachment: Screenshot 2015-09-03 17.08.40.png


Attaching screenshot showing additional header.

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 17:52:00 2015
From: issues at jboss.org (Mike Millson (JIRA))
Date: Thu, 3 Sep 2015 17:52:00 -0400 (EDT)
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.1441317082198@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583917.1441317082000.2310.1441317120137@Atlassian.JIRA>

Mike Millson created WFLY-5275:
----------------------------------

             Summary: Connection Factory parameter disappears after code deployment
                 Key: WFLY-5275
                 URL: https://issues.jboss.org/browse/WFLY-5275
             Project: WildFly
          Issue Type: Bug
            Reporter: Mike Millson
            Assignee: Jason Greene


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:

<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>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 17:53:00 2015
From: issues at jboss.org (Mike Millson (JIRA))
Date: Thu, 3 Sep 2015 17:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5276) Connection Factory parameter
 disappears after code deployment
In-Reply-To: <JIRA.12583918.1441317122000@Atlassian.JIRA>
References: <JIRA.12583918.1441317122000@Atlassian.JIRA>
	<JIRA.12583918.1441317122134@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583918.1441317122000.2312.1441317180112@Atlassian.JIRA>

Mike Millson created WFLY-5276:
----------------------------------

             Summary: Connection Factory parameter disappears after code deployment
                 Key: WFLY-5276
                 URL: https://issues.jboss.org/browse/WFLY-5276
             Project: WildFly
          Issue Type: Bug
            Reporter: Mike Millson
            Assignee: Jason Greene


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:

<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>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 17:54:00 2015
From: issues at jboss.org (Mike Millson (JIRA))
Date: Thu, 3 Sep 2015 17:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5276) Connection Factory parameter
 disappears after code deployment
In-Reply-To: <JIRA.12583918.1441317122000@Atlassian.JIRA>
References: <JIRA.12583918.1441317122000@Atlassian.JIRA>
	<JIRA.12583918.1441317122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583918.1441317122000.2319.1441317240136@Atlassian.JIRA>


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

Mike Millson closed WFLY-5276.
------------------------------
    Resolution: Done


Duplicate of WFLY-5275.

> Connection Factory parameter disappears after code deployment
> -------------------------------------------------------------
>
>                 Key: WFLY-5276
>                 URL: https://issues.jboss.org/browse/WFLY-5276
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Mike Millson
>            Assignee: Jason Greene
>
> 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:
> <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>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 17:56:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 3 Sep 2015 17:56:00 -0400 (EDT)
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.2327.1441317360307@Atlassian.JIRA>


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

Brad Maxwell updated WFLY-5275:
-------------------------------
    Description: 
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}

  was:
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:

<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>




> Connection Factory parameter disappears after code deployment
> -------------------------------------------------------------
>
>                 Key: WFLY-5275
>                 URL: https://issues.jboss.org/browse/WFLY-5275
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Mike Millson
>            Assignee: Jason Greene
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 17:56:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 3 Sep 2015 17:56:00 -0400 (EDT)
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.2323.1441317360244@Atlassian.JIRA>


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

Brad Maxwell updated WFLY-5275:
-------------------------------
    Workaround Description: 
Configure min-pool-size as a child element of xa-pool to a value other than the default 0. For example:

{code}
<connection-definitions>
    <connection-definition
          class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory"
          jndi-name="java:/ConnectionFactory"
          enabled="true"
          pool-name="ConnectionFactory">
        <xa-pool>
            <min-pool-size>1</min-pool-size>
...
        </xa-pool>
...
    </connection-definition>
</connection-definitions>
{code}

  was:
Configure min-pool-size as a child element of xa-pool to a value other than the default 0. For example:

<connection-definitions>
    <connection-definition
          class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory"
          jndi-name="java:/ConnectionFactory"
          enabled="true"
          pool-name="ConnectionFactory">
        <xa-pool>
            <min-pool-size>1</min-pool-size>
...
        </xa-pool>
...
    </connection-definition>
</connection-definitions>



> Connection Factory parameter disappears after code deployment
> -------------------------------------------------------------
>
>                 Key: WFLY-5275
>                 URL: https://issues.jboss.org/browse/WFLY-5275
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Mike Millson
>            Assignee: Jason Greene
>
> 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:
> <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>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 18:08:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 3 Sep 2015 18:08:00 -0400 (EDT)
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.2341.1441318080115@Atlassian.JIRA>


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

Brad Maxwell updated WFLY-5275:
-------------------------------
    Component/s: JCA


> 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: Jason Greene
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 18:15:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Sep 2015 18:15:00 -0400 (EDT)
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.2359.1441318500982@Atlassian.JIRA>


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

RH Bugzilla Integration updated WFLY-5275:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1259952
        Bugzilla Update: Perform


> 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: Jason Greene
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 19:33:00 2015
From: issues at jboss.org (Patson Luk (JIRA))
Date: Thu, 3 Sep 2015 19:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-251) Support looking up nested
 class with non standard anonymous class name (from Scala)
In-Reply-To: <JIRA.12583930.1441323152000@Atlassian.JIRA>
References: <JIRA.12583930.1441323152000@Atlassian.JIRA>
	<JIRA.12583930.1441323152924@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583930.1441323152000.2424.1441323180141@Atlassian.JIRA>

Patson Luk created JASSIST-251:
----------------------------------

             Summary: Support looking up nested class with non standard anonymous class name (from Scala)
                 Key: JASSIST-251
                 URL: https://issues.jboss.org/browse/JASSIST-251
             Project: Javassist
          Issue Type: Feature Request
            Reporter: Patson Luk
            Assignee: Shigeru Chiba
         Attachments: Test$$anonfun$main$1.class, Test$.class

The existing code within CtClassType.getNestedClasses() uses check 

{code}
 if (name.lastIndexOf('$') < thisName.length())
{code}
To check if the names from the "InnerClasses" attribute are the immediate nested class of the current CtClassType instance.

This works fine for well formatted anonymous class name that adheres to the Java Language spec that:
{quote}
The binary name of an anonymous class (?15.9.5) consists of the binary
name of its immediately enclosing type, followed by $, followed by a nonempty
sequence of digits.
{quote}

However, for JVM language like Scala that converts anonymous class to names that do not follow that standard, for sample code like
{code}
object Test {
   def main(args: Array[String]): Unit = {
    val list = List(1, 2, 3)
    println(list.map(_ * 2))
  }
}
{code} 

generates several java class files. Two class files (attached) in particular "Test$.class" and "Test$$anonfun$main$1.class" show "immediate nested classes" relationship in the generated byte code as
# Test$ has InnerClasses attribute entry with name "Test$$anonfun$main$1" 
# Test$$anonfun$main$1 has EnclosingMethod attribute value "Test$.main"

But "Test$$anonfun$main$1.class" does not conform to the JLS naming (otherwise it should have been "Test$$1.class" instead)

With the current check in place for getNestedClasses(), the anonymous class will not be returned as an immediate nested class of "Test$", however with a minor change it should be able to do that:

{code}
// if it is an immediate nested class
//if (name.lastIndexOf('$') < thisName.length()) instead of checking name, check the actual declaring class
CtClass nestedClass = classPool.get(name);
CtClass declaringClass = nestedClass.getDeclaringClass();
if (declaringClass == null || declaringClass.equals(this)) {
    list.add(nestedClass);
}
{code}

I tagged this as a feature request as i do not know the policy of supporting non Java language.

Please kindly advise and many thanks in advance!





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep  3 22:51:00 2015
From: issues at jboss.org (Thomas Leung (JIRA))
Date: Thu, 3 Sep 2015 22:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.2486.1441335060187@Atlassian.JIRA>


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

Thomas Leung commented on DROOLS-890:
-------------------------------------

We did build from Drools source on 6.2.0.Final with the change following your provided link https://github.com/droolsjbpm/drools/commit/183518527.
Basically it mainly synchronize the method public synchronized Class<?> defineClass(String name, String resourceName, byte[] bytecode).

However, the same deadlock issue still happened while we run a load test again.

This deadlock happened always when we run load test during the past couple of weeks. We noticed that everytime it locked at the below line in ProjectClassLoader.java:

        protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
            try {
                return loadType(name, resolve);
            } catch (ClassNotFoundException cnfe) {
                synchronized(projectClassLoader) {
                    try {
                        return projectClassLoader.internalLoadClass(name, resolve);            <== wait for lock projectClassLoader object
                    } catch (ClassNotFoundException cnfe2) {
                        return projectClassLoader.tryDefineType(name, cnfe);
                    }
                }
            }
        }

That means it throws ClassNotFoundException in loadType(name, resolve). Is it an expected exception in normal usage or it happened abnormally?

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 22:56:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 3 Sep 2015 22:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5258) Unexpected behavior of
 negative priorities in container filters
In-Reply-To: <JIRA.12583505.1441166124000@Atlassian.JIRA>
References: <JIRA.12583505.1441166124000@Atlassian.JIRA>
	<JIRA.12583505.1441166124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583505.1441166124000.2489.1441335360115@Atlassian.JIRA>


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

Stuart Douglas updated WFLY-5258:
---------------------------------
    Component/s: REST
                     (was: Web (Undertow))


> Unexpected behavior of negative priorities in container filters
> ---------------------------------------------------------------
>
>                 Key: WFLY-5258
>                 URL: https://issues.jboss.org/browse/WFLY-5258
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 9.0.1.Final
>         Environment: Windows/Linux
>            Reporter: Andreas Redmer
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> Annotation a class that implements ContainerRequestFilter with @Priority(Integer.MIN_VALUE) works as expected. The filter is executed first. For ContainerResponseFilter it is executed in random order.
> Priority values should generally be non-negative, with negative values reserved for special meanings such as "undefined" or "not specified". A specification that defines use of the Priority annotation may define the range of allowed priorities and any priority values with special meaning.
> In this case the behaviour for negative Priorities is inconsistent between the 2 container filters. The correct way to work around this is to annotate:
> @Priority(0)
> Even though: many internet tutorials suggest:
> @Priority(Integer.MIN_VALUE)
> The implemntation oif logging filter in Glassfish does that too: https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/filter/LoggingFilter.java



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep  3 23:03:00 2015
From: issues at jboss.org (Thomas Leung (JIRA))
Date: Thu, 3 Sep 2015 23:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.2497.1441335780204@Atlassian.JIRA>


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

Thomas Leung commented on DROOLS-890:
-------------------------------------

Also, another hint is that we observed it always happened in one of our drl rule which it eval an local function and then this function call another local function.

e.g. In test.drl :
rule "A"
when eval(function1(...))
then .....
end

function boolean function1(...) {
    return function2(...);
}

function boolean function2(...) {
    return true;
}

I reviewed the generated java from this drl and seems like Drools will compile all functions to individual classes and the rule class  import static the function1 class and then function1 class will import static the function2 class. Just wonder if this will cause the ClassNotFoundException or not ? Our functions are not likely causing ClassNotFoundException as it just does some string manipulations.


> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 00:25:00 2015
From: issues at jboss.org (Abrham Kampur (JIRA))
Date: Fri, 4 Sep 2015 00:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-902) Drools map usage nullpointer
	exception
In-Reply-To: <JIRA.12583933.1441340652000@Atlassian.JIRA>
References: <JIRA.12583933.1441340652000@Atlassian.JIRA>
	<JIRA.12583933.1441340652238@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583933.1441340652000.2527.1441340700311@Atlassian.JIRA>

Abrham Kampur created DROOLS-902:
------------------------------------

             Summary: Drools map usage nullpointer exception
                 Key: DROOLS-902
                 URL: https://issues.jboss.org/browse/DROOLS-902
             Project: Drools
          Issue Type: Feature Request
          Components: core engine
    Affects Versions: 5.6.0.Final
            Reporter: Abrham Kampur
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 00:25:00 2015
From: issues at jboss.org (Abrham Kampur (JIRA))
Date: Fri, 4 Sep 2015 00:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-903) Drools map usage nullpointer
	exception
In-Reply-To: <JIRA.12583934.1441340678000@Atlassian.JIRA>
References: <JIRA.12583934.1441340678000@Atlassian.JIRA>
	<JIRA.12583934.1441340678767@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583934.1441340678000.2530.1441340700401@Atlassian.JIRA>

Abrham Kampur created DROOLS-903:
------------------------------------

             Summary: Drools map usage nullpointer exception
                 Key: DROOLS-903
                 URL: https://issues.jboss.org/browse/DROOLS-903
             Project: Drools
          Issue Type: Feature Request
          Components: core engine
    Affects Versions: 5.6.0.Final
            Reporter: Abrham Kampur
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 00:36:00 2015
From: issues at jboss.org (Abrham Kampur (JIRA))
Date: Fri, 4 Sep 2015 00:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-903) Drools map usage nullpointer
	exception
In-Reply-To: <JIRA.12583934.1441340678000@Atlassian.JIRA>
References: <JIRA.12583934.1441340678000@Atlassian.JIRA>
	<JIRA.12583934.1441340678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583934.1441340678000.2533.1441341360229@Atlassian.JIRA>


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

Abrham Kampur updated DROOLS-903:
---------------------------------
    Description: 
My rules file looks like

rule"rule1 test"
when    rules:Rules(rules.getRulesParamMap().get("01").getActual()>=rules.getRulesParamMap().get("01").getThreshold())
then
          RuleResult ruleResult=new RuleResult()
          ruleResult.setRulePassed(false);
       rules.getRulesResultMap().put("01",ruleResult);
 System.out.println("Rule failed. ");

  retract(rules)

end

Note: Rules is a clas which has rulesParamMap and ruleResultMap attributes.
         Ruleresult is also a class with fields actual and threshold


> Drools map usage nullpointer exception
> --------------------------------------
>
>                 Key: DROOLS-903
>                 URL: https://issues.jboss.org/browse/DROOLS-903
>             Project: Drools
>          Issue Type: Feature Request
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Abrham Kampur
>            Assignee: Mario Fusco
>
> My rules file looks like
> rule"rule1 test"
> when    rules:Rules(rules.getRulesParamMap().get("01").getActual()>=rules.getRulesParamMap().get("01").getThreshold())
> then
>           RuleResult ruleResult=new RuleResult()
>           ruleResult.setRulePassed(false);
>        rules.getRulesResultMap().put("01",ruleResult);
>  System.out.println("Rule failed. ");
>   retract(rules)
> end
> Note: Rules is a clas which has rulesParamMap and ruleResultMap attributes.
>          Ruleresult is also a class with fields actual and threshold



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 01:53:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Sep 2015 01:53:00 -0400 (EDT)
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.2577.1441345980148@Atlassian.JIRA>


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

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

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1259952|https://bugzilla.redhat.com/show_bug.cgi?id=1259952] from NEW to ASSIGNED

> 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: Jason Greene
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 02:06:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Sep 2015 02:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1960) NioConnection: interestOps()
 called on wrong channel
In-Reply-To: <JIRA.12583935.1441346733000@Atlassian.JIRA>
References: <JIRA.12583935.1441346733000@Atlassian.JIRA>
	<JIRA.12583935.1441346733237@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583935.1441346733000.2583.1441346760197@Atlassian.JIRA>

Bela Ban created JGRP-1960:
------------------------------

             Summary: NioConnection: interestOps() called on wrong channel
                 Key: JGRP-1960
                 URL: https://issues.jboss.org/browse/JGRP-1960
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.6.6


When we accept a connection in NioServer, we set the of key of {{NioConnection}} to the one associated with the ServerSocketChannel. Later, when {{key.interestOps(key.interestOps() | SelectionKet.OP_WRITE)}} is called, an IllegalArgumentException will be thrown because a ServerSocketChannel doesn't support this op (only {{OP_ACCEPT}}).
SOLUTION: grab the {{SocketChannel}} returned from {{ServerSocketChannel.accept()}} and use *it* instead of the {{ServerSocketChannel}} to call {{interestOps()}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 03:25:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Sep 2015 03:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1960) NioConnection: interestOps()
 called on wrong channel
In-Reply-To: <JIRA.12583935.1441346733000@Atlassian.JIRA>
References: <JIRA.12583935.1441346733000@Atlassian.JIRA>
	<JIRA.12583935.1441346733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583935.1441346733000.2780.1441351500200@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1960:
--------------------------------

This is not a critical bug and *does not cause incorrect behavior*, as an {{NioConnection.send()}} which fails and tries to register an OP_WRITE will throw an IllegalArgumentException. However, that exception causes the connection to be closed, removed and re-established; this time via a connect to the peer (SocketChannel).
Since JGroups performs retransmission at the uper layers, the message will eventually be resent. This doesn't apply to messages emitted from protocols below {{UNICAST3}} though...

> NioConnection: interestOps() called on wrong channel
> ----------------------------------------------------
>
>                 Key: JGRP-1960
>                 URL: https://issues.jboss.org/browse/JGRP-1960
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> When we accept a connection in NioServer, we set the of key of {{NioConnection}} to the one associated with the ServerSocketChannel. Later, when {{key.interestOps(key.interestOps() | SelectionKet.OP_WRITE)}} is called, an IllegalArgumentException will be thrown because a ServerSocketChannel doesn't support this op (only {{OP_ACCEPT}}).
> SOLUTION: grab the {{SocketChannel}} returned from {{ServerSocketChannel.accept()}} and use *it* instead of the {{ServerSocketChannel}} to call {{interestOps()}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 05:16:02 2015
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Fri, 4 Sep 2015 05:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-868) CLI if/else is not handling
 special characters strings with parenthesis
In-Reply-To: <JIRA.12580331.1438762375000@Atlassian.JIRA>
References: <JIRA.12580331.1438762375000@Atlassian.JIRA>
	<JIRA.12580331.1438762375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580331.1438762375000.3089.1441358162185@Atlassian.JIRA>


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

Alessio Soldano reassigned WFCORE-868:
--------------------------------------

    Assignee: Alexey Loubyansky  (was: Alessio Soldano)


> CLI if/else is not handling special characters strings with parenthesis
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-868
>                 URL: https://issues.jboss.org/browse/WFCORE-868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Tomas Hofman
>            Assignee: Alexey Loubyansky
>
> When using CLI if-else scripting that uses a string that contains parenthesis it fails with the following message:
> Failed to handle 'if (outcome == success && result.value != "a64180c0)e7187af86b435229de904104") of /system-property=test:read-resource': Unexpected operation at 49 in '(outcome == success && result.value != "a64180c0)e7187af86b435229de904104")'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 05:20:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Sep 2015 05:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-902) Drools map usage nullpointer
	exception
In-Reply-To: <JIRA.12583933.1441340652000@Atlassian.JIRA>
References: <JIRA.12583933.1441340652000@Atlassian.JIRA>
	<JIRA.12583933.1441340652000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583933.1441340652000.3101.1441358400269@Atlassian.JIRA>


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

Mario Fusco closed DROOLS-902.
------------------------------
    Resolution: Duplicate Issue


This is a duplicate of https://issues.jboss.org/browse/DROOLS-903

> Drools map usage nullpointer exception
> --------------------------------------
>
>                 Key: DROOLS-902
>                 URL: https://issues.jboss.org/browse/DROOLS-902
>             Project: Drools
>          Issue Type: Feature Request
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Abrham Kampur
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 05:24:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Sep 2015 05:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-903) Drools map usage nullpointer
	exception
In-Reply-To: <JIRA.12583934.1441340678000@Atlassian.JIRA>
References: <JIRA.12583934.1441340678000@Atlassian.JIRA>
	<JIRA.12583934.1441340678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583934.1441340678000.3119.1441358640193@Atlassian.JIRA>


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

Mario Fusco updated DROOLS-903:
-------------------------------
    Issue Type: Bug  (was: Feature Request)


> Drools map usage nullpointer exception
> --------------------------------------
>
>                 Key: DROOLS-903
>                 URL: https://issues.jboss.org/browse/DROOLS-903
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Abrham Kampur
>            Assignee: Mario Fusco
>
> My rules file looks like
> rule"rule1 test"
> when    rules:Rules(rules.getRulesParamMap().get("01").getActual()>=rules.getRulesParamMap().get("01").getThreshold())
> then
>           RuleResult ruleResult=new RuleResult()
>           ruleResult.setRulePassed(false);
>        rules.getRulesResultMap().put("01",ruleResult);
>  System.out.println("Rule failed. ");
>   retract(rules)
> end
> Note: Rules is a clas which has rulesParamMap and ruleResultMap attributes.
>          Ruleresult is also a class with fields actual and threshold



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 05:34:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Sep 2015 05:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-903) Drools map usage nullpointer
	exception
In-Reply-To: <JIRA.12583934.1441340678000@Atlassian.JIRA>
References: <JIRA.12583934.1441340678000@Atlassian.JIRA>
	<JIRA.12583934.1441340678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583934.1441340678000.3183.1441359240173@Atlassian.JIRA>


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

Mario Fusco resolved DROOLS-903.
--------------------------------
    Resolution: Out of Date


Provided that the rulesParamMap always has a not null value for key "01" (otherwise the problem is in your data or you should add the constraint getRulesParamMap().get("01") != null to your rule) I think that your problem could be caused by the fact that you're using the 'rules' declaration also inside the pattern that could be rewritten as it follows

{{Rules(getRulesParamMap().get("01").getActual()>=getRulesParamMap().get("01").getThreshold())}}

While using the declaration inside its own pattern is not technical wrong, it is considered bad style and can cause some problem on 5.x that anyway have been already solved on 6.x.

> Drools map usage nullpointer exception
> --------------------------------------
>
>                 Key: DROOLS-903
>                 URL: https://issues.jboss.org/browse/DROOLS-903
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.6.0.Final
>            Reporter: Abrham Kampur
>            Assignee: Mario Fusco
>
> My rules file looks like
> rule"rule1 test"
> when    rules:Rules(rules.getRulesParamMap().get("01").getActual()>=rules.getRulesParamMap().get("01").getThreshold())
> then
>           RuleResult ruleResult=new RuleResult()
>           ruleResult.setRulePassed(false);
>        rules.getRulesResultMap().put("01",ruleResult);
>  System.out.println("Rule failed. ");
>   retract(rules)
> end
> Note: Rules is a clas which has rulesParamMap and ruleResultMap attributes.
>          Ruleresult is also a class with fields actual and threshold



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 05:49:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 4 Sep 2015 05:49:00 -0400 (EDT)
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.1441360127514@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583971.1441360127000.3228.1441360140177@Atlassian.JIRA>

Harald Pehl created WFLY-5277:
---------------------------------

             Summary: 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.Beta1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 05:50:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 4 Sep 2015 05:50:00 -0400 (EDT)
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.3230.1441360200234@Atlassian.JIRA>


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

Harald Pehl updated WFLY-5277:
------------------------------
    Fix Version/s: 10.0.0.CR1
                       (was: 10.0.0.Beta1)


> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 05:50:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 4 Sep 2015 05:50:00 -0400 (EDT)
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.3232.1441360200380@Atlassian.JIRA>


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

Harald Pehl updated WFLY-5277:
------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/7900)


> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 07:18:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 07:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5278) SSO doesn't work for webapps
 with different context name
In-Reply-To: <JIRA.12583994.1441365427000@Atlassian.JIRA>
References: <JIRA.12583994.1441365427000@Atlassian.JIRA>
	<JIRA.12583994.1441365427336@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583994.1441365427000.3476.1441365480200@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5278:
--------------------------------------

             Summary: SSO doesn't work for webapps with different context name
                 Key: WFLY-5278
                 URL: https://issues.jboss.org/browse/WFLY-5278
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Blocker


Single Sign On doesn't work for two web applications with different context name.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 07:18:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 07:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5278) SSO doesn't work for webapps
 with different context name
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.3479.1441365480258@Atlassian.JIRA>


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

Radim Hatlapatka updated WFLY-5278:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> SSO doesn't work for webapps with different context name
> --------------------------------------------------------
>
>                 Key: WFLY-5278
>                 URL: https://issues.jboss.org/browse/WFLY-5278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> Single Sign On doesn't work for two web applications with different context name.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:27:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 4 Sep 2015 08:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579425@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.3699.1441369620132@Atlassian.JIRA>

Geoffrey De Smet created WFLY-5279:
--------------------------------------

             Summary: Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
                 Key: WFLY-5279
                 URL: https://issues.jboss.org/browse/WFLY-5279
             Project: WildFly
          Issue Type: Task
          Components: Build System
            Reporter: Geoffrey De Smet
            Assignee: Paul Gier


On Maven central [1], I can find version 8.2.2.Final which doesn't exist on wildfly.org [2].
On the other hand, on wildfly.org [2], I can find version 9.0.1.Final which isn't on Maven Central [1].

This makes testing our libraries for wildfly (with arquillian) very confusing.

[1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
[2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:27:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 4 Sep 2015 08:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.3702.1441369620176@Atlassian.JIRA>


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

Geoffrey De Smet updated WFLY-5279:
-----------------------------------
    Description: 
On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].

This makes testing our libraries for wildfly (with arquillian) very confusing.

[1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
[2] http://wildfly.org/downloads/

  was:
On Maven central [1], I can find version 8.2.2.Final which doesn't exist on wildfly.org [2].
On the other hand, on wildfly.org [2], I can find version 9.0.1.Final which isn't on Maven Central [1].

This makes testing our libraries for wildfly (with arquillian) very confusing.

[1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
[2] http://wildfly.org/downloads/



> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Paul Gier
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
> [2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:29:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 4 Sep 2015 08:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.3710.1441369740195@Atlassian.JIRA>


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

Geoffrey De Smet updated WFLY-5279:
-----------------------------------
    Description: 
On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].

This makes testing our libraries for wildfly (with arquillian) very confusing.

[1] [http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22]
[2] [http://wildfly.org/downloads/]

  was:
On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].

This makes testing our libraries for wildfly (with arquillian) very confusing.

[1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
[2] http://wildfly.org/downloads/



> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Paul Gier
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] [http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22]
> [2] [http://wildfly.org/downloads/]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:29:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 4 Sep 2015 08:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.3718.1441369740323@Atlassian.JIRA>


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

Geoffrey De Smet updated WFLY-5279:
-----------------------------------
    Description: 
On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].

This makes testing our libraries for wildfly (with arquillian) very confusing.

[1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
[2] http://wildfly.org/downloads/

  was:
On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].

This makes testing our libraries for wildfly (with arquillian) very confusing.

[1] [http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22]
[2] [http://wildfly.org/downloads/]



> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Paul Gier
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
> [2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:33:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 08:33:00 -0400 (EDT)
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.1441369938458@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584012.1441369938000.3749.1441369980951@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5280:
--------------------------------------

             Summary: 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)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Critical


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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:33:01 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 08:33:01 -0400 (EDT)
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.3752.1441369981233@Atlassian.JIRA>


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

Radim Hatlapatka updated WFLY-5280:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:33:01 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 4 Sep 2015 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.3757.1441369981480@Atlassian.JIRA>


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

Tomaz Cerar closed WFLY-5279.
-----------------------------
      Assignee: Tomaz Cerar  (was: Paul Gier)
    Resolution: Rejected


Version of boms are not stricly bound to versions of WildFly. 
They usually are aligned, but that is not something we are strict about.
As we need to address bug users find in boms and that usually requires to release new version.

For example 8.2.2 was released to address WFLY-4271
and 8.2.1 bom existed even before WildFly 8.2.1 was ever in plans to be released.


> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
> [2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:34:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 08:34:00 -0400 (EDT)
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.3760.1441370040140@Atlassian.JIRA>


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

Radim Hatlapatka updated WFLY-5280:
-----------------------------------
    Steps to Reproduce: 
Try calling :migrate operation on Web subsystem with connector defined like this:
{code:xml}
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" max-connections="100" max-post-size="2048000" enable-lookups="true" 
                    max-save-post-size="4092" />
{code}

And see that there is no migration warning even though the attribute wasn't migrated (see created http listener in undertow subsystem:
{code:xml}
<http-listener name="http" max-connections="100" max-post-size="2048000" resolve-peer-address="true" socket-binding="http"/>
{code}


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:46:01 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 08:46:01 -0400 (EDT)
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.1441370753539@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584014.1441370753000.3842.1441370761397@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5281:
--------------------------------------

             Summary: [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)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas


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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:47:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 08:47:00 -0400 (EDT)
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.3850.1441370820331@Atlassian.JIRA>


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

Radim Hatlapatka updated WFLY-5281:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> [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: Stuart Douglas
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 08:49:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 4 Sep 2015 08:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.3857.1441370940076@Atlassian.JIRA>


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

Geoffrey De Smet commented on WFLY-5279:
----------------------------------------

>From a user's perspective it's confusing that 8.2.1 bom doesn't match widfly 8.2.1 but 8.2.0 instead - maybe for future similar cases it would be called 8.2.0.1 instead, so there's room for 8.2.1?
We definitely have a potential issue due to this, as we're using wildfly 8.2.1 with wildfly-bom 8.2.1 which is apparently a bad combination.

Any reason why the 9.0.1.Final bom isn't available on Maven Central?


> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
> [2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 09:31:01 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 09:31:01 -0400 (EDT)
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.1441373460329@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584019.1441373460000.4047.1441373461131@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5282:
--------------------------------------

             Summary: [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


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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 10:11:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 4 Sep 2015 10:11:00 -0400 (EDT)
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.4245.1441375860215@Atlassian.JIRA>


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

Tomaz Cerar reassigned WFLY-5278:
---------------------------------

    Issue Type: Enhancement  (was: Bug)
       Summary: default path for SSO should be /  (was: SSO doesn't work for webapps with different context name)
      Assignee: Tomaz Cerar  (was: Stuart Douglas)


> 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
>
> Single Sign On doesn't work for two web applications with different context name.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 10:18:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 4 Sep 2015 10:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4923) improve transaction timeout
 handling in JPA container with
 TransactionListenerRegistry/TransactionListener
In-Reply-To: <JIRA.12577992.1436881851000@Atlassian.JIRA>
References: <JIRA.12577992.1436881851000@Atlassian.JIRA>
	<JIRA.12577992.1436881851000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577992.1436881851000.4265.1441376280114@Atlassian.JIRA>


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

Scott Marlow closed WFLY-4923.
------------------------------
    Resolution: Done


> improve transaction timeout handling in JPA container with TransactionListenerRegistry/TransactionListener
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4923
>                 URL: https://issues.jboss.org/browse/WFLY-4923
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 10:26:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 10:26:00 -0400 (EDT)
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.1441376701334@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584024.1441376701000.4289.1441376760182@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5283:
--------------------------------------

             Summary: [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)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Critical


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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 10:26:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 4 Sep 2015 10:26:00 -0400 (EDT)
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.4292.1441376760278@Atlassian.JIRA>


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

Radim Hatlapatka updated WFLY-5283:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> [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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 10:45:01 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 4 Sep 2015 10:45:01 -0400 (EDT)
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.4374.1441377901307@Atlassian.JIRA>


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

Tomaz Cerar reassigned WFLY-5281:
---------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)


> [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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 10:55:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Fri, 4 Sep 2015 10:55:00 -0400 (EDT)
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.4413.1441378500412@Atlassian.JIRA>


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

Ladislav Thon commented on WFLY-5092:
-------------------------------------

Because comments to this issue contain pre-migrate steps, I'm adding post-migrate steps that are needed in standalone:

{noformat}
/extension=org.jboss.as.web:remove
/extension=org.jboss.as.messaging:remove
/extension=org.jboss.as.jacorb:remove
{noformat}

This is because the {{:migrate}} operations do not remove the extension (even though they remove the subsystem). And they can't in domain, per http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004287.html (if they could in standalone, I'm not sure).

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 10:58:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 10:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5284) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.4422.1441378680622@Atlassian.JIRA>


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

Brian Stansberry moved HAL-815 to WFLY-5284:
--------------------------------------------

              Project: WildFly  (was: HAL)
                  Key: WFLY-5284  (was: HAL-815)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
          Component/s: Clustering
                           (was: Subsystem Configuration)
    Affects Version/s: 10.0.0.Beta2
                           (was: 2.8.x)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5284
>                 URL: https://issues.jboss.org/browse/WFLY-5284
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep  4 11:10:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 4 Sep 2015 11:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.4491.1441379400460@Atlassian.JIRA>


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

Tomaz Cerar commented on WFLY-5279:
-----------------------------------

There is room to fix anything :-)

there was release for 9.0.1 as there was no change in WildFly that would need one.
this is change diff https://github.com/wildfly/wildfly/compare/9.0.0.Final...9.0.1.Final
There ware no components upgrades which is usually the reason for new bom release.

What is your problem with 8.2.1 bom and wildfly 8.2.1?
Best version of 8.x bom would definitively be 8.2.2 which has quite lots of things fixed due to not importing broken resteasy bom.



> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
> [2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 11:39:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 4 Sep 2015 11:39:00 -0400 (EDT)
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.4680.1441381140249@Atlassian.JIRA>


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

Tomaz Cerar updated WFLY-5278:
------------------------------
    Fix Version/s: 10.0.0.CR1


> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 12:15:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 12:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-956) Adding JGroups stack seems
 to freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.4845.1441383301166@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-5284 to WFCORE-956:
-----------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-956  (was: WFLY-5284)
          Component/s: Domain Management
                           (was: Clustering)
    Affects Version/s: 2.0.0.Beta5
                           (was: 10.0.0.Beta2)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFCORE-956
>                 URL: https://issues.jboss.org/browse/WFCORE-956
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep  4 12:25:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 12:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-956) Adding JGroups stack seems
 to freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.4888.1441383900336@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-956:
-----------------------------------------

I moved this to WFCORE as a preliminary look doesn't show anything particular to clustering happening.

Perhaps it has something to do with the alias resource being addressed; perhaps something else.

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFCORE-956
>                 URL: https://issues.jboss.org/browse/WFCORE-956
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep  4 12:49:00 2015
From: issues at jboss.org (Brian Riehman (JIRA))
Date: Fri, 4 Sep 2015 12:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-957) Wildfly not respecting
 subdeployment dependency order
In-Reply-To: <JIRA.12584046.1441385326000@Atlassian.JIRA>
References: <JIRA.12584046.1441385326000@Atlassian.JIRA>
	<JIRA.12584046.1441385326399@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584046.1441385326000.4969.1441385340567@Atlassian.JIRA>

Brian Riehman created WFCORE-957:
------------------------------------

             Summary: Wildfly not respecting subdeployment dependency order
                 Key: WFCORE-957
                 URL: https://issues.jboss.org/browse/WFCORE-957
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Brian Riehman
            Priority: Minor
         Attachments: wildfly-deployment-order.ear, wildfly-deployment-order.tar.gz

When loading an EAR with {{initialize-in-order}} set to {{true}} within the {{application.xml}} and subdeployment dependencies defined in{{jboss-deployment-structure.xml}}, Wildfly does not load the EAR modules in order as specified nor as defined by the dependencies.

I have attached both a [source repository|https://github.com/briehman/wildfly-deployment-order] and the generated EAR. The {{application.xml}} and {{jboss-deployment-structure.xml}} are as below:

{code}
<?xml version="1.0" encoding="UTF-8"?>
<application 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/application_6.xsd" version="6">
  <display-name>ear</display-name>
  <initialize-in-order>true</initialize-in-order>
  <module>
    <web>
      <web-uri>webapp-one-1.0-SNAPSHOT.war</web-uri>
      <context-root>/one</context-root>
    </web>
  </module>
  <module>
    <web>
      <web-uri>webapp-two-1.0-SNAPSHOT.war</web-uri>
      <context-root>/two</context-root>
    </web>
  </module>
  <module>
    <web>
      <web-uri>webapp-three-1.0-SNAPSHOT.war</web-uri>
      <context-root>/three</context-root>
    </web>
  </module>
</application>
{code}

{code}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <sub-deployment name="webapp-one-1.0-SNAPSHOT.war">
    </sub-deployment>
    <sub-deployment name="webapp-two-1.0-SNAPSHOT.war">
        <dependencies>
            <module name="deployment.wildfly-deployment-order.ear.webapp-one-1.0-SNAPSHOT.war" />
        </dependencies>
    </sub-deployment>
    <sub-deployment name="webapp-three-1.0-SNAPSHOT.war">
        <dependencies>
            <module name="deployment.wildfly-deployment-order.ear.webapp-two-1.0-SNAPSHOT.war" />
        </dependencies>
    </sub-deployment>
</jboss-deployment-structure>
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 12:49:00 2015
From: issues at jboss.org (Nick Sawadsky (JIRA))
Date: Fri, 4 Sep 2015 12:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.4974.1441385340721@Atlassian.JIRA>


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

Nick Sawadsky commented on JGRP-1957:
-------------------------------------

Having thought about it a little more, I don't see any straight-forward fix either. Maybe we'll just have to live with the config-based workaround. I'm fine with closing this one.

> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.6
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 13:02:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Sep 2015 13:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-958) Bump the model and schema
 version of the Remoting subsystem.
In-Reply-To: <JIRA.12584050.1441386078000@Atlassian.JIRA>
References: <JIRA.12584050.1441386078000@Atlassian.JIRA>
	<JIRA.12584050.1441386078257@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584050.1441386078000.5033.1441386120511@Atlassian.JIRA>

Darran Lofthouse created WFCORE-958:
---------------------------------------

             Summary: Bump the model and schema version of the Remoting subsystem.
                 Key: WFCORE-958
                 URL: https://issues.jboss.org/browse/WFCORE-958
             Project: WildFly Core
          Issue Type: Task
          Components: Remoting
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 15:18:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Sep 2015 15:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-899) Kie-ci sends MavenRequest
 without considering the repositories defined in user settings file
In-Reply-To: <JIRA.12583317.1441037294000@Atlassian.JIRA>
References: <JIRA.12583317.1441037294000@Atlassian.JIRA>
	<JIRA.12583317.1441037294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583317.1441037294000.5453.1441394280289@Atlassian.JIRA>


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

RH Bugzilla Integration commented on DROOLS-899:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1259589|https://bugzilla.redhat.com/show_bug.cgi?id=1259589] from NEW to MODIFIED

> Kie-ci sends MavenRequest without considering the repositories defined in user settings file
> --------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-899
>                 URL: https://issues.jboss.org/browse/DROOLS-899
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 17:56:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 17:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-959) Handling of
 ManagementResourceRegistration runtimeOnly is broken
In-Reply-To: <JIRA.12584074.1441403701000@Atlassian.JIRA>
References: <JIRA.12584074.1441403701000@Atlassian.JIRA>
	<JIRA.12584074.1441403701670@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584074.1441403701000.5727.1441403760086@Atlassian.JIRA>

Brian Stansberry created WFCORE-959:
---------------------------------------

             Summary: Handling of ManagementResourceRegistration runtimeOnly is broken
                 Key: WFCORE-959
                 URL: https://issues.jboss.org/browse/WFCORE-959
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta6
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR1


NodeSubregistry is always passing 'false' as the runtimeOnly param for ConcreteResourceRegistrations it creates.

The param isn't actually needed, since the ResourceDefinition is also a param, and the value can be pulled from it.

Also, since we now have proper facilities for setting up a runtimeOnly ResourceDefinition, the MRR.setRuntimeOnly() method should be deprecated and all core uses of it converted.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:01:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-960)
 CapabilityRegistryResourceDefinition is ignoring CapabilityScope in its
 reporting
In-Reply-To: <JIRA.12584075.1441404040000@Atlassian.JIRA>
References: <JIRA.12584075.1441404040000@Atlassian.JIRA>
	<JIRA.12584075.1441404040887@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584075.1441404040000.5730.1441404061219@Atlassian.JIRA>

Brian Stansberry created WFCORE-960:
---------------------------------------

             Summary: CapabilityRegistryResourceDefinition is ignoring CapabilityScope in its reporting
                 Key: WFCORE-960
                 URL: https://issues.jboss.org/browse/WFCORE-960
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta6
            Reporter: Brian Stansberry
            Assignee: Tomaz Cerar
             Fix For: 3.0.0.Alpha1


The keys for the different registrations in the CapabilityRegistry is their id, which is a combination of their name and their CapabilityScope. CapabilityRegistryResourceDefinition when it reports the registrations is ignoring the scope.

For WildFly Core 2.0.0.CR1 I'm going to disable registration of CapabilityRegistryResourceDefinition. We don't have specific management client use of this management API yet and it can still use some massaging, so committing ourselves to supporting the current API for many years isn't worth it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:17:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-961)
 CapabilityRegistryResourceDefinition provides inconsistent ordering of
 output
In-Reply-To: <JIRA.12584077.1441404999000@Atlassian.JIRA>
References: <JIRA.12584077.1441404999000@Atlassian.JIRA>
	<JIRA.12584077.1441404999198@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584077.1441404999000.5740.1441405020080@Atlassian.JIRA>

Brian Stansberry created WFCORE-961:
---------------------------------------

             Summary: CapabilityRegistryResourceDefinition provides inconsistent ordering of output
                 Key: WFCORE-961
                 URL: https://issues.jboss.org/browse/WFCORE-961
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta6
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR1


The output from CapabilityRegistryResourceDefinition is inconsistently ordered. We want consistent output between reads.

The RegistrationPoints are stored in CapabilityRegistration in a LinkedHashSet, but when they are provided to CapabilityRegistryResourceDefinition they get put in a plain HashSet.

The capabilities themselves are not stored in any order, but when provided to CapabilityRegistryResourceDefinition they could be ordered.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:51:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-621) Support legacy slaves when
 invoking wildcard reads in a domain
In-Reply-To: <JIRA.12567601.1427988452000@Atlassian.JIRA>
References: <JIRA.12567601.1427988452000@Atlassian.JIRA>
	<JIRA.12567601.1427988452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567601.1427988452000.5767.1441407060168@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-621:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1028, https://github.com/wildfly/wildfly/pull/8052  (was: https://github.com/wildfly/wildfly-core/pull/1022, https://github.com/wildfly/wildfly/pull/8052)


> Support legacy slaves when invoking wildcard reads in a domain
> --------------------------------------------------------------
>
>                 Key: WFCORE-621
>                 URL: https://issues.jboss.org/browse/WFCORE-621
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.Beta6
>
>
> This is a follow-on to WFCORE-282.
> The WFCORE-282 solution will not work for requests with address patterns {code}/host=*/server=*{code} or {code}/host=somename/server=*{code} if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.)
> In particular, it won't work with slaves running EAP 6.x.
> The problem is with either of those address patterns the DC will send a request addressed to {code}/host=somename/server=*{code} to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them.
> Potentially this could be fixed by having the DC detect these patterns and not call {code}/host=somename/server=*{code}, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-946) CLI Hangs in 'quit'
In-Reply-To: <JIRA.12583585.1441202553000@Atlassian.JIRA>
References: <JIRA.12583585.1441202553000@Atlassian.JIRA>
	<JIRA.12583585.1441202553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583585.1441202553000.5771.1441407182053@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-946:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> CLI Hangs in 'quit'
> -------------------
>
>                 Key: WFCORE-946
>                 URL: https://issues.jboss.org/browse/WFCORE-946
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Joe Wertz
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>         Attachments: quit-hang.txt
>
>
> If you enter the 'quit' command, the CLI hangs.
> I'll attach a thread dump.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-912) Properly register all
 capabilites on ResourceDefinition
In-Reply-To: <JIRA.12582553.1440512853000@Atlassian.JIRA>
References: <JIRA.12582553.1440512853000@Atlassian.JIRA>
	<JIRA.12582553.1440512853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582553.1440512853000.5774.1441407182108@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-912:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Properly register all capabilites on ResourceDefinition
> -------------------------------------------------------
>
>                 Key: WFCORE-912
>                 URL: https://issues.jboss.org/browse/WFCORE-912
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>
> As part of WFCORE-806, warning log message was added to AbstractAddStepHandler#recordCapabilitiesAndRequirements to point out resources that don't have properly registered capabilities on resource definition.
> This task is to fix all such cases and than add assert instead of that log message 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.5777.1441407182389@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-909:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-903) Resubmit fixed version of
	WFCORE-860
In-Reply-To: <JIRA.12582252.1440277918000@Atlassian.JIRA>
References: <JIRA.12582252.1440277918000@Atlassian.JIRA>
	<JIRA.12582252.1440277918000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582252.1440277918000.5781.1441407182457@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-903:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Resubmit fixed version of WFCORE-860
> ------------------------------------
>
>                 Key: WFCORE-903
>                 URL: https://issues.jboss.org/browse/WFCORE-903
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Jason Greene
>            Assignee: ehsavoie Hugonnet
>             Fix For: 2.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.5791.1441407182625@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-840:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-841) Patching module testsuite
	failure
In-Reply-To: <JIRA.12579359.1437766085000@Atlassian.JIRA>
References: <JIRA.12579359.1437766085000@Atlassian.JIRA>
	<JIRA.12579359.1437766085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579359.1437766085000.5787.1441407182547@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-841:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Patching module testsuite failure
> ---------------------------------
>
>                 Key: WFCORE-841
>                 URL: https://issues.jboss.org/browse/WFCORE-841
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Patching 
>         Environment: $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> OS X Yosemite 10.10.4
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.CR1
>
>
> When running the core build locally , the 'patching' module testsuite fails:
> {code}
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
> Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
> testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase)  Time elapsed: 0.044 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
> 	at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
> 	at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
> {code}
> If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order.
> Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround.
> The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-826) List-* operations should
 accept also objects as value
In-Reply-To: <JIRA.12578306.1437060543000@Atlassian.JIRA>
References: <JIRA.12578306.1437060543000@Atlassian.JIRA>
	<JIRA.12578306.1437060543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578306.1437060543000.5798.1441407182919@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-826:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> List-* operations should accept also objects as value
> -----------------------------------------------------
>
>                 Key: WFCORE-826
>                 URL: https://issues.jboss.org/browse/WFCORE-826
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> in case where list contains objects and not just simple types 
> list operations complain:
> example:
> {noformat}
> [standalone at localhost:9990 /] /subsystem=messaging-activemq/server=default:list-add(name=incoming-interceptors, value={name=foo,module=bar})
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0097: Wrong type for value. Expected [STRING] but was OBJECT",
>     "rolled-back" => true
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-785) Improve capability related
	error messages
In-Reply-To: <JIRA.12576642.1435679852000@Atlassian.JIRA>
References: <JIRA.12576642.1435679852000@Atlassian.JIRA>
	<JIRA.12576642.1435679852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576642.1435679852000.5801.1441407182970@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-785:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Improve capability related error messages
> -----------------------------------------
>
>                 Key: WFCORE-785
>                 URL: https://issues.jboss.org/browse/WFCORE-785
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
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.5783.1441407182486@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: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> "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: 2.0.0.CR1
>
>
> 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. The "jts" attribute in the transactions subsystem comes to mind.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-836)
 PersistentResourceXMLDescription should mashall default values by default
In-Reply-To: <JIRA.12579199.1437666691000@Atlassian.JIRA>
References: <JIRA.12579199.1437666691000@Atlassian.JIRA>
	<JIRA.12579199.1437666691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579199.1437666691000.5795.1441407182830@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-836:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> PersistentResourceXMLDescription should mashall default values by default
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-836
>                 URL: https://issues.jboss.org/browse/WFCORE-836
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Blocker
>             Fix For: 2.0.0.CR1
>
>
> marshalDefaults  should be true by default in parser.
> Also we would need an option to override this in parser definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.5805.1441407183104@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-756:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-597) Where an
 ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on
 contained types for add operations.
In-Reply-To: <JIRA.12565854.1426262411000@Atlassian.JIRA>
References: <JIRA.12565854.1426262411000@Atlassian.JIRA>
	<JIRA.12565854.1426262411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565854.1426262411000.5817.1441407183305@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-597:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-597
>                 URL: https://issues.jboss.org/browse/WFCORE-597
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>              Labels: affects_elytron
>             Fix For: 2.0.0.CR1
>
>
> If an ObjectTypeAttributeDefinition contains an attribute definition that has ResourceOnly set then it should be filtered from the automatically generated description for the add operation.
> This may be more related to lists, I currently have: -
> ObjectListAttributeDefinition, which contains ObjectTypeAttributeDefinition, which contains SimpleAttributeDefinition
> It is this final SimpleAttributeDefinition that has ResourceOnly set but it is still showing up in the operation description for add.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.5810.1441407183189@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-628:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-603) Simplify working with
	complex attributes
In-Reply-To: <JIRA.12566094.1426595216000@Atlassian.JIRA>
References: <JIRA.12566094.1426595216000@Atlassian.JIRA>
	<JIRA.12566094.1426595216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566094.1426595216000.5813.1441407183241@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-603:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Simplify working with complex attributes
> ----------------------------------------
>
>                 Key: WFCORE-603
>                 URL: https://issues.jboss.org/browse/WFCORE-603
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> This is umbrella issue for all complex attributes related enhancements and simplifications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-364) Hangs in mixed domain
	testsuite
In-Reply-To: <JIRA.12494340.1371247934000@Atlassian.JIRA>
References: <JIRA.12494340.1371247934000@Atlassian.JIRA>
	<JIRA.12494340.1371247934000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494340.1371247934000.5838.1441407183792@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-364:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Hangs in mixed domain testsuite
> -------------------------------
>
>                 Key: WFCORE-364
>                 URL: https://issues.jboss.org/browse/WFCORE-364
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>         Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt
>
>
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull/7449/console
> https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details.
> 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain.
> "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163)
> 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave.
> "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738)
> (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.)
> 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback.
> "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173)
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337)
> 	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128)
> Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-403) Evaluate making operation
 "composite" EntryType.PUBLIC
In-Reply-To: <JIRA.12491057.1367612465000@Atlassian.JIRA>
References: <JIRA.12491057.1367612465000@Atlassian.JIRA>
	<JIRA.12491057.1367612465000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491057.1367612465000.5830.1441407183620@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-403:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Evaluate making operation "composite" EntryType.PUBLIC
> ------------------------------------------------------
>
>                 Key: WFCORE-403
>                 URL: https://issues.jboss.org/browse/WFCORE-403
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>
> When the composite operation handler is registered, it's marked as EntryType.PRIVATE. This operation really isn't private; any reasonable management client will need to invoke it.
> Changing it may have some implications though; we need to evaluate those. The biggest is the operation metadata cannot be complete, because the step parameter elements cannot be fully described.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-646) Product to Project Schema
	and Model Sync
In-Reply-To: <JIRA.12568717.1429281526000@Atlassian.JIRA>
References: <JIRA.12568717.1429281526000@Atlassian.JIRA>
	<JIRA.12568717.1429281526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568717.1429281526000.5808.1441407183155@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-646:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Product to Project Schema and Model Sync
> ----------------------------------------
>
>                 Key: WFCORE-646
>                 URL: https://issues.jboss.org/browse/WFCORE-646
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR1
>
>
> Periodic sync of EAP schemas with WildFly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-365) inconsistent usage of
 min/max-occurs in model description
In-Reply-To: <JIRA.12470576.1342507607000@Atlassian.JIRA>
References: <JIRA.12470576.1342507607000@Atlassian.JIRA>
	<JIRA.12470576.1342507607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470576.1342507607000.5835.1441407183743@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-365:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> inconsistent usage of min/max-occurs in model description
> ---------------------------------------------------------
>
>                 Key: WFCORE-365
>                 URL: https://issues.jboss.org/browse/WFCORE-365
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>         Attachments: patch.txt
>
>
> The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation.
> I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it.
> [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+Model



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-471) pre/post cli-scripts for AS
 patching feature
In-Reply-To: <JIRA.12475775.1349017637000@Atlassian.JIRA>
References: <JIRA.12475775.1349017637000@Atlassian.JIRA>
	<JIRA.12475775.1349017637000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475775.1349017637000.5824.1441407183453@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-471:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> pre/post cli-scripts for AS patching feature
> --------------------------------------------
>
>                 Key: WFCORE-471
>                 URL: https://issues.jboss.org/browse/WFCORE-471
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Patching , Scripts
>            Reporter: Nicklas Karlsson
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.CR1
>
>
> It would be handy to be able to attach pre/post CLI scripts to be applied for an AS patch.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.5827.1441407183562@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-459:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.CR1
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:03 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.5845.1441407183958@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-310:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR1
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:04 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-296) Switch URI scheme from
 remoting:// http-remoting:// https-remoting:// to remote:// remote+http://
 and remote+https://
In-Reply-To: <JIRA.12542570.1401734598000@Atlassian.JIRA>
References: <JIRA.12542570.1401734598000@Atlassian.JIRA>
	<JIRA.12542570.1401734598000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542570.1401734598000.5853.1441407184231@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-296:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-296
>                 URL: https://issues.jboss.org/browse/WFCORE-296
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI, Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR1
>
>
> From [~dmlloyd]
> {quote}
> When we have multi-layer protocol going on, the URI scheme we should use 
> is like this:
>    outer+middle+inner://
> {quote}
> Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> The existing schemes will be needed for backwards compatibility but somehow deprecated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:04 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-278) Revisit error message for an
 authentication failure.
In-Reply-To: <JIRA.12536929.1396443828000@Atlassian.JIRA>
References: <JIRA.12536929.1396443828000@Atlassian.JIRA>
	<JIRA.12536929.1396443828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536929.1396443828000.5856.1441407184287@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-278:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Revisit error message for an authentication failure.
> ----------------------------------------------------
>
>                 Key: WFCORE-278
>                 URL: https://issues.jboss.org/browse/WFCORE-278
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR1
>
>
> After authentication fails in the CLI the following error message is output: -
> {code}
> Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms
> {code}
> This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:04 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to
 domain-management module
In-Reply-To: <JIRA.12553769.1412093571000@Atlassian.JIRA>
References: <JIRA.12553769.1412093571000@Atlassian.JIRA>
	<JIRA.12553769.1412093571000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553769.1412093571000.5859.1441407184347@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-137:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Add Kerberos tests to domain-management module
> ----------------------------------------------
>
>                 Key: WFCORE-137
>                 URL: https://issues.jboss.org/browse/WFCORE-137
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:04 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-103) Add Full Kerberos Support
In-Reply-To: <JIRA.12467133.1337768128000@Atlassian.JIRA>
References: <JIRA.12467133.1337768128000@Atlassian.JIRA>
	<JIRA.12467133.1337768128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467133.1337768128000.5869.1441407184606@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-103:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Add Full Kerberos Support
> -------------------------
>
>                 Key: WFCORE-103
>                 URL: https://issues.jboss.org/browse/WFCORE-103
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: management_security,
>             Fix For: 2.0.0.CR1
>
>
> There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:04 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-60) Capabilities and requirements
 in a managed process
In-Reply-To: <JIRA.12549680.1408475027000@Atlassian.JIRA>
References: <JIRA.12549680.1408475027000@Atlassian.JIRA>
	<JIRA.12549680.1408475027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549680.1408475027000.5872.1441407184709@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-60:
-----------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Capabilities and requirements in a managed process
> --------------------------------------------------
>
>                 Key: WFCORE-60
>                 URL: https://issues.jboss.org/browse/WFCORE-60
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>
> Implement the aspects discussed under the "Runtime" section of https://community.jboss.org/docs/DOC-52712
> Add an API to the OperationContext for handlers to publish capabilities and for other handlers to register a requirement for those capabilities and to access the API object associated with the capability.
> The registry of capabilities and requirements should be maintained with a semantic equivalent to the resource tree. The registry is copied-on-write, making the copy invisible to concurrently executing operations, and then the copy is published on commit of the operation that modified it. If the operation does not commit, the copy is discarded, so handlers have no need to revert changes they make to the registry.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 18:53:05 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 18:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in
	bin
In-Reply-To: <JIRA.12472505.1344994425000@Atlassian.JIRA>
References: <JIRA.12472505.1344994425000@Atlassian.JIRA>
	<JIRA.12472505.1344994425000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472505.1344994425000.5883.1441407185083@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-25:
-----------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta6)


> Windows PowerShell scripts in bin
> ---------------------------------
>
>                 Key: WFCORE-25
>                 URL: https://issues.jboss.org/browse/WFCORE-25
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 19:05:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 4 Sep 2015 19:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-364) Hangs in mixed domain
	testsuite
In-Reply-To: <JIRA.12494340.1371247934000@Atlassian.JIRA>
References: <JIRA.12494340.1371247934000@Atlassian.JIRA>
	<JIRA.12494340.1371247934000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494340.1371247934000.5887.1441407900940@Atlassian.JIRA>


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

Brian Stansberry resolved WFCORE-364.
-------------------------------------
    Fix Version/s:     (was: 2.0.0.CR1)
       Resolution: Out of Date


I haven't heard any cases of this for a long time.

> Hangs in mixed domain testsuite
> -------------------------------
>
>                 Key: WFCORE-364
>                 URL: https://issues.jboss.org/browse/WFCORE-364
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>         Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt
>
>
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull/7449/console
> https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details.
> 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain.
> "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163)
> 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave.
> "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738)
> (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.)
> 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback.
> "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173)
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337)
> 	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128)
> Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 20:16:01 2015
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 4 Sep 2015 20:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-904) Trait proxy classes are not
 recreated on persistent session deserialization
In-Reply-To: <JIRA.12584081.1441412121000@Atlassian.JIRA>
References: <JIRA.12584081.1441412121000@Atlassian.JIRA>
	<JIRA.12584081.1441412121055@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584081.1441412121000.5915.1441412161665@Atlassian.JIRA>

Davide Sottara created DROOLS-904:
-------------------------------------

             Summary: Trait proxy classes are not recreated on persistent session deserialization
                 Key: DROOLS-904
                 URL: https://issues.jboss.org/browse/DROOLS-904
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.3.0.CR2, 6.3.0.CR1, 6.2.0.Final, 6.1.0.Final, 6.0.1.Final, 6.0.0.Final, 5.6.0.Final, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Davide Sottara
            Priority: Blocker


Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
Deserializing a previously persisted session containing a proxy instance requires the 
proxy class to be available to the KieBase's project class loader by the time the session is
restored. However, a freshly recreated KieBase for the purpose of restoring a session will
not have the proper classes loaded.

The proxy class bytecode is deserialized correctly (in JavaDialectRuntimeData), but
not loaded by the PCL in a timely fashion.

Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.

 




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 20:17:00 2015
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 4 Sep 2015 20:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-904) Trait proxy classes are not
 reloaded on persistent session deserialization
In-Reply-To: <JIRA.12584081.1441412121000@Atlassian.JIRA>
References: <JIRA.12584081.1441412121000@Atlassian.JIRA>
	<JIRA.12584081.1441412121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584081.1441412121000.5917.1441412220064@Atlassian.JIRA>


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

Davide Sottara updated DROOLS-904:
----------------------------------
    Summary: Trait proxy classes are not reloaded on persistent session deserialization  (was: Trait proxy classes are not recreated on persistent session deserialization)


> Trait proxy classes are not reloaded on persistent session deserialization
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-904
>                 URL: https://issues.jboss.org/browse/DROOLS-904
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.CR1, 6.3.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Blocker
>
> Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
> Deserializing a previously persisted session containing a proxy instance requires the 
> proxy class to be available to the KieBase's project class loader by the time the session is
> restored. However, a freshly recreated KieBase for the purpose of restoring a session will
> not have the proper classes loaded.
> The proxy class bytecode is deserialized correctly (in JavaDialectRuntimeData), but
> not loaded by the PCL in a timely fashion.
> Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 20:18:00 2015
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 4 Sep 2015 20:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-904) Trait proxy classes are not
 reloaded on persistent session deserialization
In-Reply-To: <JIRA.12584081.1441412121000@Atlassian.JIRA>
References: <JIRA.12584081.1441412121000@Atlassian.JIRA>
	<JIRA.12584081.1441412121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584081.1441412121000.5919.1441412280104@Atlassian.JIRA>


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

Davide Sottara updated DROOLS-904:
----------------------------------
    Description: 
Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
Deserializing a previously persisted session containing a proxy instance requires the 
proxy class to be available to the KieBase's project class loader by the time the session is
restored. However, a freshly recreated KieBase for the purpose of restoring a session will
not have the proper classes loaded.

Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.

 


  was:
Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
Deserializing a previously persisted session containing a proxy instance requires the 
proxy class to be available to the KieBase's project class loader by the time the session is
restored. However, a freshly recreated KieBase for the purpose of restoring a session will
not have the proper classes loaded.

The proxy class bytecode is deserialized correctly (in JavaDialectRuntimeData), but
not loaded by the PCL in a timely fashion.

Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.

 




> Trait proxy classes are not reloaded on persistent session deserialization
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-904
>                 URL: https://issues.jboss.org/browse/DROOLS-904
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.CR1, 6.3.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Blocker
>
> Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
> Deserializing a previously persisted session containing a proxy instance requires the 
> proxy class to be available to the KieBase's project class loader by the time the session is
> restored. However, a freshly recreated KieBase for the purpose of restoring a session will
> not have the proper classes loaded.
> Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep  4 20:18:00 2015
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 4 Sep 2015 20:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-904) Trait proxy classes are not
 restored on persistent session deserialization
In-Reply-To: <JIRA.12584081.1441412121000@Atlassian.JIRA>
References: <JIRA.12584081.1441412121000@Atlassian.JIRA>
	<JIRA.12584081.1441412121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584081.1441412121000.5921.1441412280249@Atlassian.JIRA>


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

Davide Sottara updated DROOLS-904:
----------------------------------
    Summary: Trait proxy classes are not restored on persistent session deserialization  (was: Trait proxy classes are not reloaded on persistent session deserialization)


> Trait proxy classes are not restored on persistent session deserialization
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-904
>                 URL: https://issues.jboss.org/browse/DROOLS-904
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.CR1, 6.3.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Blocker
>
> Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
> Deserializing a previously persisted session containing a proxy instance requires the 
> proxy class to be available to the KieBase's project class loader by the time the session is
> restored. However, a freshly recreated KieBase for the purpose of restoring a session will
> not have the proper classes loaded.
> Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep  5 04:56:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sat, 5 Sep 2015 04:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed
 from .list file
In-Reply-To: <JIRA.12583349.1441056567000@Atlassian.JIRA>
References: <JIRA.12583349.1441056567000@Atlassian.JIRA>
	<JIRA.12583349.1441056567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583349.1441056567000.6061.1441443360335@Atlassian.JIRA>


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

Bela Ban closed JGRP-1957.
--------------------------
    Resolution: Rejected


> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
>                 Key: JGRP-1957
>                 URL: https://issues.jboss.org/browse/JGRP-1957
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>         Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.6
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3. 
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3. 
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep  5 08:13:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 5 Sep 2015 08:13:00 -0400 (EDT)
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.1441455141346@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584088.1441455141000.6066.1441455180160@Atlassian.JIRA>

Brian Stansberry created WFLY-5285:
--------------------------------------

             Summary: 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
(v6.4.11#64026)

From issues at jboss.org  Sat Sep  5 08:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 5 Sep 2015 08:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-962) PersistentResourceDefinition
 should accept a Parameters constructor
In-Reply-To: <JIRA.12584089.1441456748000@Atlassian.JIRA>
References: <JIRA.12584089.1441456748000@Atlassian.JIRA>
	<JIRA.12584089.1441456748663@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584089.1441456748000.6069.1441456800288@Atlassian.JIRA>

Brian Stansberry created WFCORE-962:
---------------------------------------

             Summary: PersistentResourceDefinition should accept a Parameters constructor
                 Key: WFCORE-962
                 URL: https://issues.jboss.org/browse/WFCORE-962
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Tomaz Cerar


PersistentResourceDefinition's constructor should accept a future-extensible Parameters object like the superclass does. Ideally it would be the same class, but if that's not a fit for the semantics of PersistentResourceDefinition, a different class is ok.

I stumbled on this when fixing WFLY-5285 when I couldn't use Parameters as the standard fix for messaging's SecurityRoleDefinition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep  5 09:49:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 5 Sep 2015 09:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-962) PersistentResourceDefinition
 should accept a Parameters constructor
In-Reply-To: <JIRA.12584089.1441456748000@Atlassian.JIRA>
References: <JIRA.12584089.1441456748000@Atlassian.JIRA>
	<JIRA.12584089.1441456748000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584089.1441456748000.6072.1441460940371@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-962:
------------------------------------
    Priority: Minor  (was: Major)


> PersistentResourceDefinition should accept a Parameters constructor
> -------------------------------------------------------------------
>
>                 Key: WFCORE-962
>                 URL: https://issues.jboss.org/browse/WFCORE-962
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> PersistentResourceDefinition's constructor should accept a future-extensible Parameters object like the superclass does. Ideally it would be the same class, but if that's not a fit for the semantics of PersistentResourceDefinition, a different class is ok.
> I stumbled on this when fixing WFLY-5285 when I couldn't use Parameters as the standard fix for messaging's SecurityRoleDefinition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep  5 09:49:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 5 Sep 2015 09:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-962) PersistentResourceDefinition
 should accept a Parameters constructor
In-Reply-To: <JIRA.12584089.1441456748000@Atlassian.JIRA>
References: <JIRA.12584089.1441456748000@Atlassian.JIRA>
	<JIRA.12584089.1441456748000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584089.1441456748000.6075.1441460940491@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-962:
------------------------------------
    Description: 
PersistentResourceDefinition's constructor should accept a future-extensible Parameters object like the superclass does. Ideally it would be the same class, but if that's not a fit for the semantics of PersistentResourceDefinition, a different class is ok.

I stumbled on this when fixing WFLY-5285 when I couldn't use Parameters as the standard fix for messaging's SecurityRoleDefinition, although that didn't really matter.

  was:
PersistentResourceDefinition's constructor should accept a future-extensible Parameters object like the superclass does. Ideally it would be the same class, but if that's not a fit for the semantics of PersistentResourceDefinition, a different class is ok.

I stumbled on this when fixing WFLY-5285 when I couldn't use Parameters as the standard fix for messaging's SecurityRoleDefinition.



> PersistentResourceDefinition should accept a Parameters constructor
> -------------------------------------------------------------------
>
>                 Key: WFCORE-962
>                 URL: https://issues.jboss.org/browse/WFCORE-962
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> PersistentResourceDefinition's constructor should accept a future-extensible Parameters object like the superclass does. Ideally it would be the same class, but if that's not a fit for the semantics of PersistentResourceDefinition, a different class is ok.
> I stumbled on this when fixing WFLY-5285 when I couldn't use Parameters as the standard fix for messaging's SecurityRoleDefinition, although that didn't really matter.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep  5 12:23:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sat, 5 Sep 2015 12:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126410@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6179.1441470180176@Atlassian.JIRA>

Bela Ban created JGRP-1961:
------------------------------

             Summary: TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
                 Key: JGRP-1961
                 URL: https://issues.jboss.org/browse/JGRP-1961
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.6.5
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Critical
             Fix For: 3.6.6


When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {m1}} and {{m2}}).
This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
A quick check where buffers were copied fixed the problem.
TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 06:29:00 2015
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Sun, 6 Sep 2015 06:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-905) OSGi: support Equinox when
 running on Karaf
In-Reply-To: <JIRA.12584097.1441535302000@Atlassian.JIRA>
References: <JIRA.12584097.1441535302000@Atlassian.JIRA>
	<JIRA.12584097.1441535302651@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584097.1441535302000.6268.1441535340092@Atlassian.JIRA>

Petr ?irok? created DROOLS-905:
----------------------------------

             Summary: OSGi: support Equinox when running on Karaf
                 Key: DROOLS-905
                 URL: https://issues.jboss.org/browse/DROOLS-905
             Project: Drools
          Issue Type: Feature Request
          Components: core engine
    Affects Versions: 6.3.0.CR2
            Reporter: Petr ?irok?
            Assignee: Petr ?irok?


Karaf supports two base frameworks: Felix (default) and Equinox.

Drools currently does not run correctly when Equinox is used.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sun Sep  6 06:44:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 6 Sep 2015 06:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6272.1441536240718@Atlassian.JIRA>


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

Bela Ban updated JGRP-1961:
---------------------------
    Description: 
When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
A quick check where buffers were copied fixed the problem.
TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.

  was:
When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {m1}} and {{m2}}).
This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
A quick check where buffers were copied fixed the problem.
TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 07:04:00 2015
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Sun, 6 Sep 2015 07:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-905) OSGi: support Equinox when
 running on Karaf
In-Reply-To: <JIRA.12584097.1441535302000@Atlassian.JIRA>
References: <JIRA.12584097.1441535302000@Atlassian.JIRA>
	<JIRA.12584097.1441535302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584097.1441535302000.6273.1441537440075@Atlassian.JIRA>


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

Petr ?irok? resolved DROOLS-905.
--------------------------------
    Fix Version/s: 7.0.0.Final
       Resolution: Done


> OSGi: support Equinox when running on Karaf
> -------------------------------------------
>
>                 Key: DROOLS-905
>                 URL: https://issues.jboss.org/browse/DROOLS-905
>             Project: Drools
>          Issue Type: Feature Request
>          Components: core engine
>    Affects Versions: 6.3.0.CR2
>            Reporter: Petr ?irok?
>            Assignee: Petr ?irok?
>             Fix For: 7.0.0.Final
>
>
> Karaf supports two base frameworks: Felix (default) and Equinox.
> Drools currently does not run correctly when Equinox is used.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sun Sep  6 11:00:01 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 6 Sep 2015 11:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6283.1441551601581@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1961:
--------------------------------

For non-bundled messages, we create a new buffer for every message: those buffers are not reused. In contrast, message bundlers create a buffer (initial size: 1024 bytes) which is always reused and thus potentially increases.
Perhaps we need to abandon this and create a new buffer in bundlers for every message, too, like for non bundled messages...
Downside: this affects {{TCP}} and {{UDP}} which don't need to copy. 
Is blindly copying in {{TCP_PING}} an option ? The copies would be unneeded for non-bundled messages, but I guess most messages are bundled, so this should be ok...

> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 11:01:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 6 Sep 2015 11:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6287.1441551660158@Atlassian.JIRA>


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

Bela Ban edited comment on JGRP-1961 at 9/6/15 11:00 AM:
---------------------------------------------------------

For non-bundled messages, we create a new buffer for every message: those buffers are not reused. In contrast, message bundlers create a buffer (initial size: 1024 bytes) which is always reused and thus potentially increases.
Perhaps we need to abandon this and create a new buffer in bundlers for every message, too, like for non bundled messages...
Downside: this affects {{TCP}} and {{UDP}} which don't need to copy. 
Is blindly copying in {{TCP_PING}} an option ? The copies would be unneeded for non-bundled messages, but I guess most messages are bundled, so this should be ok...
Copying in {{TCP_NIO2}} is similar to copying in {{TCP}}, with send-queues being enabled...


was (Author: belaban):
For non-bundled messages, we create a new buffer for every message: those buffers are not reused. In contrast, message bundlers create a buffer (initial size: 1024 bytes) which is always reused and thus potentially increases.
Perhaps we need to abandon this and create a new buffer in bundlers for every message, too, like for non bundled messages...
Downside: this affects {{TCP}} and {{UDP}} which don't need to copy. 
Is blindly copying in {{TCP_PING}} an option ? The copies would be unneeded for non-bundled messages, but I guess most messages are bundled, so this should be ok...

> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 11:05:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 6 Sep 2015 11:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6291.1441551900077@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1961:
--------------------------------

Hmm, how about we push the copy logic into {{WriteBuffers}} which could be configured to enable/disable copying on an unsuccessful write: if a {{write(b1,b2,b3,b4)}} was unsuccessful and only wrote {{b1}}, {{b2}} and *parts of* {{b3}}, then null {{b1}} and {{b2}} and *copy* {{b3}} and {{b4}}, leaving {{position}} and {{limit}} of {{b3}} and{{b4}} intact.
Hmm, what happens if the next write also fails ? How do we prevent an additional copy ?

> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 11:06:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 6 Sep 2015 11:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6294.1441551960077@Atlassian.JIRA>


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

Bela Ban edited comment on JGRP-1961 at 9/6/15 11:05 AM:
---------------------------------------------------------

Hmm, how about we push the copy logic into {{WriteBuffers}} which could be configured to enable/disable copying on an unsuccessful write: if a {{write(b1,b2,b3,b4)}} was unsuccessful and only wrote {{b1}}, {{b2}} and *parts of* {{b3}}, but not {{b4}}, then null {{b1}} and {{b2}} and *copy* {{b3}} and {{b4}}, leaving {{position}} and {{limit}} of {{b3}} and {{b4}} intact.
Hmm, what happens if the next write also fails ? How do we prevent an additional copy ?


was (Author: belaban):
Hmm, how about we push the copy logic into {{WriteBuffers}} which could be configured to enable/disable copying on an unsuccessful write: if a {{write(b1,b2,b3,b4)}} was unsuccessful and only wrote {{b1}}, {{b2}} and *parts of* {{b3}}, then null {{b1}} and {{b2}} and *copy* {{b3}} and {{b4}}, leaving {{position}} and {{limit}} of {{b3}} and{{b4}} intact.
Hmm, what happens if the next write also fails ? How do we prevent an additional copy ?

> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 16:32:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Sun, 6 Sep 2015 16:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-963) Add capability for IO worker
 thread pool size
In-Reply-To: <JIRA.12584101.1441571516000@Atlassian.JIRA>
References: <JIRA.12584101.1441571516000@Atlassian.JIRA>
	<JIRA.12584101.1441571516878@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584101.1441571516000.6318.1441571520098@Atlassian.JIRA>

Jason Greene created WFCORE-963:
-----------------------------------

             Summary: Add capability for IO worker thread pool size
                 Key: WFCORE-963
                 URL: https://issues.jboss.org/browse/WFCORE-963
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Jason Greene
            Assignee: Jason Greene
             Fix For: 2.0.0.CR1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 17:46:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Sun, 6 Sep 2015 17:46:00 -0400 (EDT)
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.6327.1441575960955@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-3171:
---------------------------------
    Fix Version/s: 10.0.0.CR1


> 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
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 18:05:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 6 Sep 2015 18:05:00 -0400 (EDT)
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.6331.1441577100437@Atlassian.JIRA>


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

Stuart Douglas resolved WFLY-5281.
----------------------------------
    Fix Version/s: 10.0.0.CR1
       Resolution: Done


The default path is now "/"

> [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
(v6.4.11#64026)

From issues at jboss.org  Sun Sep  6 22:30:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 6 Sep 2015 22:30:00 -0400 (EDT)
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.6351.1441593000359@Atlassian.JIRA>


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

Stuart Douglas resolved WFLY-5206.
----------------------------------
    Resolution: Done


> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 00:27:00 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Mon, 7 Sep 2015 00:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.6402.1441600020224@Atlassian.JIRA>


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

?? ? updated DROOLS-880:
------------------------
    Attachment: method_not_allowed.png


> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 00:27:00 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Mon, 7 Sep 2015 00:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.6406.1441600020366@Atlassian.JIRA>


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

?? ? commented on DROOLS-880:
-----------------------------

I tested with 'drools.6.3.0.CR2'. But It returned message '405 Method Not Allowed'.
!method_not_allowed.png|thumbnail!

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 01:58:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 01:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
In-Reply-To: <JIRA.12366075.1219398846000@Atlassian.JIRA>
References: <JIRA.12366075.1219398846000@Atlassian.JIRA>
	<JIRA.12366075.1219398846000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12366075.1219398846000.6421.1441605480259@Atlassian.JIRA>


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

Bela Ban commented on JGRP-815:
-------------------------------

Correction: we can connect a *sender's* multicast socket to the mcast_addr, e.g. 
{code:java}
DatagramChannel ch=DatagramChannel.open(StandardProtocolFamily.INET)
          .setOption(StandardSocketOptions.SO_REUSEADDR, true)
          .bind(new InetSocketAddress(7500))
          .setOption(StandardSocketOptions.IP_MULTICAST_IF, ni);
SocketAddress mcast_addr=new InetSocketAddress(addr, 7500);
ch.connect(mcast_addr);
{code}

This allows us to use _gathering writes_ to send multiple buffers in one go. On the receiver side, we cannot connect the sockets, as we don't know the IP addresses of the senders and we'll have multiple senders sending data, so scattering reads cannot be used there. 
This shouldn't be an issue though, as we may not need scattering reads on the receiver side.
See attached programs for an example: bla10 is the receiver and bla9 the sender.


> Scatter/Gather to avoid copying
> -------------------------------
>
>                 Key: JGRP-815
>                 URL: https://issues.jboss.org/browse/JGRP-815
>             Project: JGroups
>          Issue Type: Sub-task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 01:59:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 01:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
In-Reply-To: <JIRA.12366075.1219398846000@Atlassian.JIRA>
References: <JIRA.12366075.1219398846000@Atlassian.JIRA>
	<JIRA.12366075.1219398846000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12366075.1219398846000.6428.1441605540217@Atlassian.JIRA>


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

Bela Ban updated JGRP-815:
--------------------------
    Attachment: bla10.java
                bla9.java


bla10: receiver
bla9: sender

> Scatter/Gather to avoid copying
> -------------------------------
>
>                 Key: JGRP-815
>                 URL: https://issues.jboss.org/browse/JGRP-815
>             Project: JGroups
>          Issue Type: Sub-task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>         Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 02:15:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 02:15:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6435.1441606500103@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1961:
--------------------------------

Modifying {{WriteBuffers}} seems like a bad idea: a low level buffer should not be concerned about copying. I think I'll just go ahead and copy packets at the {{TCP_NIO2}} level, similar to what's currently done with send-queues in {{TCP}}. 
This code will change anyway in 4.0 when we pass a list of buffers to the send() method. Then, the JGroups header could be marshalled into a freshly created buffer as it's small anyway...

> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 03:59:00 2015
From: issues at jboss.org (Chao Wang (JIRA))
Date: Mon, 7 Sep 2015 03:59:00 -0400 (EDT)
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.6541.1441612740134@Atlassian.JIRA>


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

Chao Wang commented on WFLY-5242:
---------------------------------

wildfly PR: https://github.com/wildfly/wildfly/pull/8068

> 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: Stuart Douglas
>            Priority: Minor
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 04:07:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 7 Sep 2015 04:07:00 -0400 (EDT)
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.6556.1441613220320@Atlassian.JIRA>


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

Stuart Douglas reassigned WFLY-5242:
------------------------------------

    Assignee: Chao Wang  (was: Stuart Douglas)


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 04:31:00 2015
From: issues at jboss.org (Vivek Hingorani (JIRA))
Date: Mon, 7 Sep 2015 04:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.6592.1441614660403@Atlassian.JIRA>


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

Vivek Hingorani reopened DROOLS-890:
------------------------------------


We did a patch and fix is not working. Can you please reply to the previous comments?

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 04:51:01 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 04:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6616.1441615861592@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1961:
--------------------------------

I actually ended up with a different solution: I removed the reusable output stream in the bundling code. Now, bundlers create a new buffer for every message / message list. 
A quick perf test showed about the same perf as with the reusable buffer. Additional advantage: the reusable buffer could grow with large messages, and now this isn't the case anymore.
Plus, in 4.0, we'll have to create that buffer only for the JGroups header (src and dst addrs, headers), and the payload buffer(s) will be passed to the gathering write without serialization into a buffer.

> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:23:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Sep 2015 05:23:00 -0400 (EDT)
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.6705.1441617780243@Atlassian.JIRA>


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

RH Bugzilla Integration updated WFLY-5242:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1258298, https://bugzilla.redhat.com/show_bug.cgi?id=1260566  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1258298)


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:32:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 05:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1960) NioConnection: interestOps()
 called on wrong channel
In-Reply-To: <JIRA.12583935.1441346733000@Atlassian.JIRA>
References: <JIRA.12583935.1441346733000@Atlassian.JIRA>
	<JIRA.12583935.1441346733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583935.1441346733000.6723.1441618320412@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1960.
----------------------------
    Resolution: Done


> NioConnection: interestOps() called on wrong channel
> ----------------------------------------------------
>
>                 Key: JGRP-1960
>                 URL: https://issues.jboss.org/browse/JGRP-1960
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> When we accept a connection in NioServer, we set the of key of {{NioConnection}} to the one associated with the ServerSocketChannel. Later, when {{key.interestOps(key.interestOps() | SelectionKet.OP_WRITE)}} is called, an IllegalArgumentException will be thrown because a ServerSocketChannel doesn't support this op (only {{OP_ACCEPT}}).
> SOLUTION: grab the {{SocketChannel}} returned from {{ServerSocketChannel.accept()}} and use *it* instead of the {{ServerSocketChannel}} to call {{interestOps()}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:33:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 05:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1953) Bits: implement methods which
 read from / write to ByteBuffers
In-Reply-To: <JIRA.12581104.1439464180000@Atlassian.JIRA>
References: <JIRA.12581104.1439464180000@Atlassian.JIRA>
	<JIRA.12581104.1439464180000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581104.1439464180000.6726.1441618380238@Atlassian.JIRA>


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

Bela Ban updated JGRP-1953:
---------------------------
    Fix Version/s: 3.6.7
                       (was: 3.6.6)


> Bits: implement methods which read from / write to ByteBuffers
> --------------------------------------------------------------
>
>                 Key: JGRP-1953
>                 URL: https://issues.jboss.org/browse/JGRP-1953
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.7
>
>
> Needed for 4.0



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:34:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 05:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3
 buckets created in Frankfurt region
In-Reply-To: <JIRA.12564025.1424765791000@Atlassian.JIRA>
References: <JIRA.12564025.1424765791000@Atlassian.JIRA>
	<JIRA.12564025.1424765791000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564025.1424765791000.6730.1441618440468@Atlassian.JIRA>


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

Bela Ban updated JGRP-1914:
---------------------------
    Fix Version/s: 3.6.7
                       (was: 3.6.6)


> S3_PING doesn't work with S3 buckets created in Frankfurt region 
> -----------------------------------------------------------------
>
>                 Key: JGRP-1914
>                 URL: https://issues.jboss.org/browse/JGRP-1914
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Gleb Leonov
>            Assignee: Bela Ban
>             Fix For: 3.6.7
>
>         Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request)  error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.    



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:34:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 05:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1951) Flexible buffers for
	scatter/gather
In-Reply-To: <JIRA.12581062.1439448214000@Atlassian.JIRA>
References: <JIRA.12581062.1439448214000@Atlassian.JIRA>
	<JIRA.12581062.1439448214000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581062.1439448214000.6736.1441618440722@Atlassian.JIRA>


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

Bela Ban updated JGRP-1951:
---------------------------
    Fix Version/s: 3.6.7
                       (was: 3.6.6)


> Flexible buffers for scatter/gather
> -----------------------------------
>
>                 Key: JGRP-1951
>                 URL: https://issues.jboss.org/browse/JGRP-1951
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.7
>
>
> Currently, {{Buffers}} and {{WriteBuffers}} are inflexible in that they always expect a length buffer followed by data ({{Buffers}}), or a sequence of len/data pairs ({{WriteBuffers}}).
> This is bad if we for example want to read a sequence like the one below (for connection establishment in TCP):
> {noformat}
> | cookie | version | len | peer-address |
>    (4)         (2)      (2)     (variable)
> {noformat}
> Goals:
> * Have only 1 buffer, for reading *and* writing
> * Allow to define the sequence by adding buffers dynamically, e.g. in the above case, we'd add a 4 and a 2-length buffer and read data into them. If the cookie and version don't match, throw an exception, else *dynamically* add a length buffer (possibly doing a clear() which removes the first 2 buffers), read data into it, then add a new buffer sized to the read length and finally read data into it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:35:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 05:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1952) Compatibility between
 blocking and non-blocking TCP
In-Reply-To: <JIRA.12581063.1439448566000@Atlassian.JIRA>
References: <JIRA.12581063.1439448566000@Atlassian.JIRA>
	<JIRA.12581063.1439448566000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581063.1439448566000.6739.1441618500131@Atlassian.JIRA>


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

Bela Ban updated JGRP-1952:
---------------------------
    Fix Version/s: 3.6.7
                       (was: 3.6.6)


> Compatibility between blocking and non-blocking TCP
> ---------------------------------------------------
>
>                 Key: JGRP-1952
>                 URL: https://issues.jboss.org/browse/JGRP-1952
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.7
>
>
> * Blocking RouterStubs can talk to a non-blocking GossipRouter, and vice versa
> * Ditto for {{PubServer}} and {{PubClient}}
> * Investigate whether this would also work for {{TCP}} and {{TCP_NIO2}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:43:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Sep 2015 05:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4333) Transaction must be sticky to
 ensure consistency for EJB remote invocation with JPA
In-Reply-To: <JIRA.12562784.1423556052000@Atlassian.JIRA>
References: <JIRA.12562784.1423556052000@Atlassian.JIRA>
	<JIRA.12562784.1423556052000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562784.1423556052000.6753.1441618980889@Atlassian.JIRA>


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

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

Ryan Emerson <remerson at redhat.com> changed the Status of [bug 1190996|https://bugzilla.redhat.com/show_bug.cgi?id=1190996] from ASSIGNED to CLOSED

> Transaction must be sticky to ensure consistency for EJB remote invocation with JPA
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-4333
>                 URL: https://issues.jboss.org/browse/WFLY-4333
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomasz Adamski
>            Priority: Critical
>              Labels: ejb, transaction
>
> If an application inside of a server uses standard JavaEE persistence JPA, the current implementation include a local 1. level cache which might end in inconsistent reads within the same (uncommited) transaction.
> There are two reasons
> - JPA must not flush changes to an entity until commit
> - The 1. level cache might not read from the persistence if the entity is already loaded in a transaction
> Therefore the server to server invocations of EJB's need to be sticky to one node during a transaction. The granularity must be the application.
> It might be worth to use already known nodes for other applications as well.
> The stickyness should be enabled automatically if a transaction is active and distributed, which is the default within the current implementation, and use the loadbalancing policy if no transaction is active.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:53:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 7 Sep 2015 05:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-964) Servers in domain are not
 showing only its logs in web console
In-Reply-To: <JIRA.12580347.1438772919000@Atlassian.JIRA>
References: <JIRA.12580347.1438772919000@Atlassian.JIRA>
	<JIRA.12580347.1438772919000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580347.1438772919000.6817.1441619580373@Atlassian.JIRA>


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

Heiko Braun moved HAL-782 to WFCORE-964:
----------------------------------------

     Project: WildFly Core  (was: HAL)
         Key: WFCORE-964  (was: HAL-782)
    Workflow: GIT Pull Request workflow   (was: classic default workflow)


> Servers in domain are not showing only its logs in web console
> --------------------------------------------------------------
>
>                 Key: WFCORE-964
>                 URL: https://issues.jboss.org/browse/WFCORE-964
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Patrik Cyprian
>            Assignee: Harald Pehl
>
> If I add in domain mode some file handlers for specific profile and thus server-group and then list log files in web console for server from other server-group, files are also listed in the server in other server-group even though they shouldn't be.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 05:53:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 7 Sep 2015 05:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-964) Servers in domain are not
 showing only its logs in web console
In-Reply-To: <JIRA.12580347.1438772919000@Atlassian.JIRA>
References: <JIRA.12580347.1438772919000@Atlassian.JIRA>
	<JIRA.12580347.1438772919000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580347.1438772919000.6824.1441619580513@Atlassian.JIRA>


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

Heiko Braun reassigned WFCORE-964:
----------------------------------

    Assignee: James Perkins  (was: Harald Pehl)


> Servers in domain are not showing only its logs in web console
> --------------------------------------------------------------
>
>                 Key: WFCORE-964
>                 URL: https://issues.jboss.org/browse/WFCORE-964
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Patrik Cyprian
>            Assignee: James Perkins
>
> If I add in domain mode some file handlers for specific profile and thus server-group and then list log files in web console for server from other server-group, files are also listed in the server in other server-group even though they shouldn't be.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 06:01:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 7 Sep 2015 06:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling
 can lead to corruption of msgs sent asynchronously
In-Reply-To: <JIRA.12584090.1441470126000@Atlassian.JIRA>
References: <JIRA.12584090.1441470126000@Atlassian.JIRA>
	<JIRA.12584090.1441470126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584090.1441470126000.6849.1441620060194@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1961.
----------------------------
    Resolution: Done


> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1961
>                 URL: https://issues.jboss.org/browse/JGRP-1961
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 06:09:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Sep 2015 06:09:00 -0400 (EDT)
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.6859.1441620540228@Atlassian.JIRA>


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

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

Chao Wang <chaowan at redhat.com> changed the Status of [bug 1260566|https://bugzilla.redhat.com/show_bug.cgi?id=1260566] from NEW to POST

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 06:24:00 2015
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Mon, 7 Sep 2015 06:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5170) WildFlySecurityManager throws
 exception by some tests with security manager
In-Reply-To: <JIRA.12582201.1440168712000@Atlassian.JIRA>
References: <JIRA.12582201.1440168712000@Atlassian.JIRA>
	<JIRA.12582201.1440168712000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582201.1440168712000.6956.1441621440378@Atlassian.JIRA>


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

Ondrej Kotek reassigned WFLY-5170:
----------------------------------

    Assignee: Ondrej Kotek  (was: Josef Cacek)


> WildFlySecurityManager throws exception by some tests with security manager
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5170
>                 URL: https://issues.jboss.org/browse/WFLY-5170
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Ondrej Kotek
>
> *Description of problem:*
> WildFlySecurityManager throws ExceptionInInitializerError exception by some tests with security manager. 
> *Affected tests found so far:*
> * org.jboss.as.test.integration.batch.deployment.JobControlTestCase#testStop
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20MessageSelectorTestCase#retestMessageSelectors
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase#testEjb20MDB
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase#testEjb20TopicMDBs
> * org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB21TestCase#testSimple21MDB
> * org.jboss.as.test.integration.ejb.pool.lifecycle.PooledEJBLifecycleTestCase#testMDB
> * org.jboss.as.test.xts.annotation.compensationScoped.CompensationScopedTestCase#shouldSeeDifferentValuesInDifferentTransactions
> * org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly
> * org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple
> *Steps to Reproduce for MDB20QueueTestCase:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=MDB20QueueTestCase
> *Actual results:*
> {noformat}
> testEjb20MDB(org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase)  Time elapsed: 0.094 sec  <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:496)
> 	at java.lang.System.getProperty(System.java:717)
> 	at java.lang.Integer.getInteger(Integer.java:1101)
> 	at java.lang.Integer.getInteger(Integer.java:1057)
> 	at org.jboss.as.test.shared.TimeoutUtil.<clinit>(TimeoutUtil.java:39)
> 	at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20QueueTestCase.testEjb20MDB(MDB20QueueTestCase.java:110)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 06:27:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Sep 2015 06:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-956) Adding JGroups stack seems
 to freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.6972.1441621620268@Atlassian.JIRA>


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

Kabir Khan commented on WFCORE-956:
-----------------------------------

This sounds a lot like https://issues.jboss.org/browse/WFCORE-955

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFCORE-956
>                 URL: https://issues.jboss.org/browse/WFCORE-956
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 06:36:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Sep 2015 06:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-956) Adding JGroups stack seems
 to freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.6982.1441622160298@Atlassian.JIRA>


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

Kabir Khan edited comment on WFCORE-956 at 9/7/15 6:35 AM:
-----------------------------------------------------------

This sounds a lot like https://issues.jboss.org/browse/WFCORE-955
EDIT: I could reproduce on master with ^^ merged so it isn't that


was (Author: kabirkhan):
This sounds a lot like https://issues.jboss.org/browse/WFCORE-955

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFCORE-956
>                 URL: https://issues.jboss.org/browse/WFCORE-956
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 07:02:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 7 Sep 2015 07:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5286) Provide CLI operation which
 returns used journal type - NIOxASYNCIO
In-Reply-To: <JIRA.12584131.1441623687000@Atlassian.JIRA>
References: <JIRA.12584131.1441623687000@Atlassian.JIRA>
	<JIRA.12584131.1441623687000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584131.1441623687000.7020.1441623720310@Atlassian.JIRA>


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

Miroslav Novak moved JBEAP-1004 to WFLY-5286:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5286  (was: JBEAP-1004)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: JMS
                           (was: JMS)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.Beta2
                           (was: 7.0.0.DR9)


> Provide CLI operation which returns used journal type - NIOxASYNCIO
> -------------------------------------------------------------------
>
>                 Key: WFLY-5286
>                 URL: https://issues.jboss.org/browse/WFLY-5286
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> There is no way to get information which journal type is used using CLI as attribute journal-type provides only information which journal type is configured but not which one is actually used in runtime because Artemis falls back to NIO journal type if AIO natives are not located. New operation or attribute should be provided.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 07:31:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 7 Sep 2015 07:31:00 -0400 (EDT)
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.1441625445126@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584135.1441625445000.7177.1441625460265@Atlassian.JIRA>

Radoslav Husar created WFLY-5287:
------------------------------------

             Summary: 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: Feature Request
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 07:32:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 7 Sep 2015 07:32:00 -0400 (EDT)
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.7180.1441625520117@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-5287:
--------------------------------------

https://github.com/infinispan/infinispan/commit/8b15769fd4d608f345d95b0e1b8840188c270e33

> 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: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 08:10:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 7 Sep 2015 08:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.7249.1441627800866@Atlassian.JIRA>


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

ehsavoie Hugonnet reassigned WFCORE-949:
----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: ehsavoie Hugonnet
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 08:28:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 7 Sep 2015 08:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.7355.1441628880613@Atlassian.JIRA>


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

Mario Fusco commented on DROOLS-890:
------------------------------------

Why are you mentioning a ClassNotFoundException now? 
Did you experience it or are you just suggesting that this could happen under some specific circumstances? 
How is this related with the deadlock?

In general this start resembling more a police investigation task with some obscure clues here and there than a bug report :)
Please send me a reproducer or at least the complete stacks of the deadlocked threads, otherwise it's impossible for me to guess what's going wrong there.

Thanks,
Mario

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 08:32:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Sep 2015 08:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-956) Adding JGroups stack seems
 to freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.7375.1441629120526@Atlassian.JIRA>


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

Kabir Khan commented on WFCORE-956:
-----------------------------------

This seems to be because it is looping in the aliases. What happens when executing the CLI command is 

1) This operation comes in:
{code}
{
    "address" => [
        ("profile" => "full-ha"),
        ("subsystem" => "jgroups"),
        ("stack" => "foo"),
        ("transport" => "TRANSPORT")
    ],
    "operation" => "read-operation-description",
    "name" => "add",
    "operation-headers" => {
        "caller-type" => "user",
        "access-mechanism" => "NATIVE"
    }
}
{code}

2) It ends up in AliasStepHandler where the original address is:
{code}
[
    ("profile" => "full-ha"),
    ("subsystem" => "jgroups"),
    ("stack" => "foo"),
    ("transport" => "TRANSPORT")
]
{code}
This address is then transformed to the same, so that the 'mapped' variable in AliasStepHandler contains
{code}
[
    ("profile" => "full-ha"),
    ("subsystem" => "jgroups"),
    ("stack" => "foo"),
    ("transport" => "TRANSPORT")
]
{code}

3) AliasStepHandler then replaces the address in the operation with exactly the same, so it adds exactly the same operation as from 1) and we have the loop.

A wild guess is that it is this PR https://github.com/wildfly/wildfly/pull/7911 from [~pferraro] merged last week (unless this was already in EAP)

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFCORE-956
>                 URL: https://issues.jboss.org/browse/WFCORE-956
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 08:55:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 7 Sep 2015 08:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.7554.1441630500770@Atlassian.JIRA>


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

Edson Tirelli commented on DROOLS-880:
--------------------------------------

Please note on my screenshot that the URL had a small change. It should be:

POST .../services/rest/server/containers/instances/test

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 09:12:02 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 7 Sep 2015 09:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5288) Don't force precise sequence
 of attributes in messaging-activemq subsystem
In-Reply-To: <JIRA.12584157.1441631489000@Atlassian.JIRA>
References: <JIRA.12584157.1441631489000@Atlassian.JIRA>
	<JIRA.12584157.1441631489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584157.1441631489000.7649.1441631522070@Atlassian.JIRA>


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

Miroslav Novak moved JBEAP-1014 to WFLY-5288:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5288  (was: JBEAP-1014)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: JMS
                           (was: JMS)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.Beta2
                           (was: 7.0.0.DR9)


> Don't force precise sequence of attributes in messaging-activemq subsystem
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5288
>                 URL: https://issues.jboss.org/browse/WFLY-5288
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> In configuration of messaging-activemq subsystem we force precise sequence of attributes. It's hard to find correct place for attribute if xml is configured manually.
> For example configuration like:
> {code}
>                 <security enabled="false"/>
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
> {code}
> works but if attributes are switched:
> {code}
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
>                 <security enabled="false"/>
> {code}
> server fails to start with:
> {code}
> 15:12:18,884 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:354)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:272)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[314,17]
> Message: WFLYCTL0377: Unexpected element '{urn:jboss:domain:messaging-activemq:1.0}security' encountered. Valid elements are: 'replication-master, shared-store-master, connector-service, http-acceptor, broadcast-group, cluster-connection, bindings-directory, replication-slave, shared-store-slave, shared-store-colocated, live-only, address-setting, jms-queue, pooled-connection-factory, large-messages-directory, divert, journal-directory, in-vm-acceptor, replication-colocated, http-connector, discovery-group, remote-acceptor, acceptor, connection-factory, remote-connector, in-vm-connector, legacy-connection-factory, grouping-handler, jms-topic, connector, security-setting, bridge, paging-directory, queue'
> 	at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:98)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:286)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:279)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:605)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:66)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> 15:12:18,887 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:21:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Mon, 7 Sep 2015 09:21:00 -0400 (EDT)
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.7683.1441632060280@Atlassian.JIRA>


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

Harald Pehl updated WFLY-5224:
------------------------------
    Priority: Critical  (was: Major)


> 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: Tom Jenkinson
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:25:01 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 7 Sep 2015 09:25:01 -0400 (EDT)
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.7746.1441632301030@Atlassian.JIRA>


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

Tom Jenkinson reassigned WFLY-5224:
-----------------------------------

    Assignee: Amos Feng  (was: Tom Jenkinson)


> 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: Amos Feng
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:26:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 7 Sep 2015 09:26:00 -0400 (EDT)
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.7761.1441632360777@Atlassian.JIRA>


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

Tom Jenkinson commented on WFLY-5224:
-------------------------------------

Hi Harald,

I noticed you moved this to critical, is this intended for WFLY 10 or is WFLY 11 OK?

Thanks,
Tom

> 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: Amos Feng
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:29:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 09:29:00 -0400 (EDT)
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.7782.1441632540595@Atlassian.JIRA>


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

Tomaz Cerar resolved WFLY-5112.
-------------------------------
    Fix Version/s: 10.0.0.Beta2
       Resolution: Done


> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:30:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Mon, 7 Sep 2015 09:30:00 -0400 (EDT)
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.7803.1441632600550@Atlassian.JIRA>


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

Harald Pehl commented on WFLY-5224:
-----------------------------------

Since this blocks HAL-781, it would be great if it's fixed for WLFY 10

> 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: Amos Feng
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:37:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 7 Sep 2015 09:37:00 -0400 (EDT)
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.7816.1441633020138@Atlassian.JIRA>


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

Tom Jenkinson updated WFLY-5224:
--------------------------------
    Fix Version/s: 10.0.0.CR1


> 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: Amos Feng
>            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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:50:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 09:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5288) Don't force precise sequence
 of attributes in messaging-activemq subsystem
In-Reply-To: <JIRA.12584157.1441631489000@Atlassian.JIRA>
References: <JIRA.12584157.1441631489000@Atlassian.JIRA>
	<JIRA.12584157.1441631489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584157.1441631489000.7880.1441633800267@Atlassian.JIRA>


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

Tomaz Cerar commented on WFLY-5288:
-----------------------------------

This is result of using attribute groups and I doubt we can do anything to fix this.

When parsing an xml element that represents resource in model tree (for example /subsystem=msg/resource=me)
rules in order are:
- first parse all xml attributes on xml element, which map to attributes on resource
- then parse all attribute groups, which are sub elements that have attributes on them, that attributes are still mapped to same resource
- after all sub elements that are found to be attribute groups are parsed we move to parsing all other child elements that are mapped to child resources.

this is then looped for all elements that are found.

So in your case, "security" element is treated as attribute group, where security-setting is a sub resource.
and as long as all attribute group elements are before all sub resource elements it will work. 


> Don't force precise sequence of attributes in messaging-activemq subsystem
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5288
>                 URL: https://issues.jboss.org/browse/WFLY-5288
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> In configuration of messaging-activemq subsystem we force precise sequence of attributes. It's hard to find correct place for attribute if xml is configured manually.
> For example configuration like:
> {code}
>                 <security enabled="false"/>
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
> {code}
> works but if attributes are switched:
> {code}
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
>                 <security enabled="false"/>
> {code}
> server fails to start with:
> {code}
> 15:12:18,884 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:354)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:272)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[314,17]
> Message: WFLYCTL0377: Unexpected element '{urn:jboss:domain:messaging-activemq:1.0}security' encountered. Valid elements are: 'replication-master, shared-store-master, connector-service, http-acceptor, broadcast-group, cluster-connection, bindings-directory, replication-slave, shared-store-slave, shared-store-colocated, live-only, address-setting, jms-queue, pooled-connection-factory, large-messages-directory, divert, journal-directory, in-vm-acceptor, replication-colocated, http-connector, discovery-group, remote-acceptor, acceptor, connection-factory, remote-connector, in-vm-connector, legacy-connection-factory, grouping-handler, jms-topic, connector, security-setting, bridge, paging-directory, queue'
> 	at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:98)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:286)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:279)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:605)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:66)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> 15:12:18,887 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:50:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 09:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5288) Don't force precise sequence
 of attributes in messaging-activemq subsystem
In-Reply-To: <JIRA.12584157.1441631489000@Atlassian.JIRA>
References: <JIRA.12584157.1441631489000@Atlassian.JIRA>
	<JIRA.12584157.1441631489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584157.1441631489000.7885.1441633800517@Atlassian.JIRA>


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

Tomaz Cerar edited comment on WFLY-5288 at 9/7/15 9:49 AM:
-----------------------------------------------------------

This is result of using attribute groups and I doubt we can do anything to fix this.

When parsing an xml element that represents resource in model tree (for example /subsystem=msg/resource=me)
rules in order are:
- first parse all xml attributes on xml element, which map to attributes on resource
- then parse all attribute groups, which are sub elements that have attributes on them, that attributes are still mapped to same resource
- after all sub elements that are found to be attribute groups are parsed we move to parsing all other child elements that are mapped to child resources.

this is then looped for all elements that are found.

So in your case, "security" element is attribute group, where "security-setting" is a sub resource.
and as long as all attribute group elements are before all sub resource elements it will work. 



was (Author: ctomc):
This is result of using attribute groups and I doubt we can do anything to fix this.

When parsing an xml element that represents resource in model tree (for example /subsystem=msg/resource=me)
rules in order are:
- first parse all xml attributes on xml element, which map to attributes on resource
- then parse all attribute groups, which are sub elements that have attributes on them, that attributes are still mapped to same resource
- after all sub elements that are found to be attribute groups are parsed we move to parsing all other child elements that are mapped to child resources.

this is then looped for all elements that are found.

So in your case, "security" element is treated as attribute group, where security-setting is a sub resource.
and as long as all attribute group elements are before all sub resource elements it will work. 


> Don't force precise sequence of attributes in messaging-activemq subsystem
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5288
>                 URL: https://issues.jboss.org/browse/WFLY-5288
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> In configuration of messaging-activemq subsystem we force precise sequence of attributes. It's hard to find correct place for attribute if xml is configured manually.
> For example configuration like:
> {code}
>                 <security enabled="false"/>
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
> {code}
> works but if attributes are switched:
> {code}
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
>                 <security enabled="false"/>
> {code}
> server fails to start with:
> {code}
> 15:12:18,884 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:354)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:272)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[314,17]
> Message: WFLYCTL0377: Unexpected element '{urn:jboss:domain:messaging-activemq:1.0}security' encountered. Valid elements are: 'replication-master, shared-store-master, connector-service, http-acceptor, broadcast-group, cluster-connection, bindings-directory, replication-slave, shared-store-slave, shared-store-colocated, live-only, address-setting, jms-queue, pooled-connection-factory, large-messages-directory, divert, journal-directory, in-vm-acceptor, replication-colocated, http-connector, discovery-group, remote-acceptor, acceptor, connection-factory, remote-connector, in-vm-connector, legacy-connection-factory, grouping-handler, jms-topic, connector, security-setting, bridge, paging-directory, queue'
> 	at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:98)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:286)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:279)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:605)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:66)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> 15:12:18,887 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:51:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 09:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5288) Don't force precise sequence
 of attributes in messaging-activemq subsystem
In-Reply-To: <JIRA.12584157.1441631489000@Atlassian.JIRA>
References: <JIRA.12584157.1441631489000@Atlassian.JIRA>
	<JIRA.12584157.1441631489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584157.1441631489000.7890.1441633860294@Atlassian.JIRA>


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

Tomaz Cerar closed WFLY-5288.
-----------------------------
    Resolution: Won't Fix


I don't think there is much we can do here, beyond not using attribute groups.


> Don't force precise sequence of attributes in messaging-activemq subsystem
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5288
>                 URL: https://issues.jboss.org/browse/WFLY-5288
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> In configuration of messaging-activemq subsystem we force precise sequence of attributes. It's hard to find correct place for attribute if xml is configured manually.
> For example configuration like:
> {code}
>                 <security enabled="false"/>
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
> {code}
> works but if attributes are switched:
> {code}
>                 <security-setting name="#">
>                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
>                 </security-setting>
>                 <security enabled="false"/>
> {code}
> server fails to start with:
> {code}
> 15:12:18,884 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:354)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:272)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[314,17]
> Message: WFLYCTL0377: Unexpected element '{urn:jboss:domain:messaging-activemq:1.0}security' encountered. Valid elements are: 'replication-master, shared-store-master, connector-service, http-acceptor, broadcast-group, cluster-connection, bindings-directory, replication-slave, shared-store-slave, shared-store-colocated, live-only, address-setting, jms-queue, pooled-connection-factory, large-messages-directory, divert, journal-directory, in-vm-acceptor, replication-colocated, http-connector, discovery-group, remote-acceptor, acceptor, connection-factory, remote-connector, in-vm-connector, legacy-connection-factory, grouping-handler, jms-topic, connector, security-setting, bridge, paging-directory, queue'
> 	at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:98)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:286)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:279)
> 	at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:158)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:605)
> 	at org.wildfly.extension.messaging.activemq.MessagingSubsystemParser_1_0.readElement(MessagingSubsystemParser_1_0.java:66)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> 15:12:18,887 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 09:54:00 2015
From: issues at jboss.org (Martin Simka (JIRA))
Date: Mon, 7 Sep 2015 09:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5289) "Writes closed" when
 deploying application in domain
In-Reply-To: <JIRA.12584170.1441634039000@Atlassian.JIRA>
References: <JIRA.12584170.1441634039000@Atlassian.JIRA>
	<JIRA.12584170.1441634039919@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584170.1441634039000.7928.1441634040813@Atlassian.JIRA>

Martin Simka created WFLY-5289:
----------------------------------

             Summary: "Writes closed" when deploying application in domain
                 Key: WFLY-5289
                 URL: https://issues.jboss.org/browse/WFLY-5289
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 10.0.0.Beta2
         Environment: domain
profile=default
1x domain controller without servers
3x slave, 10 servers each
            Reporter: Martin Simka
            Assignee: Brian Stansberry


Some of our tests for large domain sometimes fail with error: "Writes closed". It happens only with some higher number of servers per host. 
{noformat}
Failed response:
{
    "outcome" => "failed",
    "result" => {
        "step-1" => {
            "outcome" => "failed",
            "rolled-back" => true
        },
        "step-2" => {
            "outcome" => "failed",
            "rolled-back" => true
        },
        "step-3" => {
            "outcome" => "failed",
            "rolled-back" => true
        }
    },
    "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
        "server-group-A" => {"host" => {
            "perf31" => {
                "perf31-server-3" => "Writes closed",
                "perf31-server-5" => "Writes closed"
            },
            "perf33" => {"perf33-server-3" => "Writes closed"}
        }},
        "server-group-B" => {"host" => {"perf32" => {
            "perf32-server-2" => "Writes closed",
            "perf32-server-6" => "Writes closed"
        }}}
    }}},
    "rolled-back" => true,
    "server-groups" => {
        "server-group-A" => {"host" => {
            "perf31" => {
                "perf31-server-1" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf31-server-3" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => "Writes closed",
                    "rolled-back" => true
                }},
                "perf31-server-5" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => "Writes closed",
                    "rolled-back" => true
                }},
                "perf31-server-7" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf31-server-9" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }}
            },
            "perf32" => {
                "perf32-server-1" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf32-server-3" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => undefined,
                    "rolled-back" => true
                }},
                "perf32-server-5" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf32-server-7" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf32-server-9" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }}
            },
            "perf33" => {
                "perf33-server-1" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf33-server-3" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => "Writes closed",
                    "rolled-back" => true
                }},
                "perf33-server-5" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf33-server-7" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf33-server-9" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }}
            }
        }},
        "server-group-B" => {"host" => {
            "perf31" => {
                "perf31-server-10" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf31-server-2" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => undefined,
                    "rolled-back" => true
                }},
                "perf31-server-4" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => undefined,
                    "rolled-back" => true
                }},
                "perf31-server-6" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf31-server-8" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }}
            },
            "perf32" => {
                "perf32-server-10" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf32-server-2" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => "Writes closed",
                    "rolled-back" => true
                }},
                "perf32-server-4" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => undefined,
                    "rolled-back" => true
                }},
                "perf32-server-6" => {"response" => {
                    "outcome" => "failed",
                    "result" => undefined,
                    "failure-description" => "Writes closed",
                    "rolled-back" => true
                }},
                "perf32-server-8" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }}
            },
            "perf33" => {
                "perf33-server-10" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf33-server-2" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf33-server-4" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf33-server-6" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }},
                "perf33-server-8" => {"response" => {
                    "outcome" => "failed",
                    "result" => {"step-1" => {
                        "outcome" => "failed",
                        "rolled-back" => true
                    }},
                    "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
                    "rolled-back" => true
                }}
            }
        }}
    }
}
{noformat}

I know this isn't detailed bug report, I didn't find easy way to reproduce it, other than running large domain tests. Tests are modified tests from https://github.com/wildfly/wildfly/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/suites/DeploymentManagementTestCase.java .

I can provide other logs, outputs ...., just let me know which log categories would help. 

Also I tried to play a bit with remoting's HEARTBEAT interval (through subsystem configuration), but that doesn't help. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 10:03:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Sep 2015 10:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.7994.1441634581458@Atlassian.JIRA>


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

Brian Stansberry moved WFCORE-956 to WFLY-5290:
-----------------------------------------------

              Project: WildFly  (was: WildFly Core)
                  Key: WFLY-5290  (was: WFCORE-956)
          Component/s: Clustering
                       Domain Management
                           (was: Domain Management)
    Affects Version/s:     (was: 2.0.0.Beta5)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 10:04:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Sep 2015 10:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.8006.1441634640467@Atlassian.JIRA>


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

Brian Stansberry reassigned WFLY-5290:
--------------------------------------

    Fix Version/s: 10.0.0.CR1
         Assignee: Paul Ferraro  (was: Brian Stansberry)


[~pferraro] Given Kabir's comment above, I'm assigning this back to you.

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 10:05:01 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-965) "Writes closed" when
 deploying application in domain
In-Reply-To: <JIRA.12584170.1441634039000@Atlassian.JIRA>
References: <JIRA.12584170.1441634039000@Atlassian.JIRA>
	<JIRA.12584170.1441634039000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584170.1441634039000.8012.1441634701384@Atlassian.JIRA>


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

Tomaz Cerar moved WFLY-5289 to WFCORE-965:
------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-965  (was: WFLY-5289)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 2.0.0.Beta6
                           (was: 10.0.0.Beta2)


> "Writes closed" when deploying application in domain
> ----------------------------------------------------
>
>                 Key: WFCORE-965
>                 URL: https://issues.jboss.org/browse/WFCORE-965
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>         Environment: domain
> profile=default
> 1x domain controller without servers
> 3x slave, 10 servers each
>            Reporter: Martin Simka
>            Assignee: Brian Stansberry
>
> Some of our tests for large domain sometimes fail with error: "Writes closed". It happens only with some higher number of servers per host. 
> {noformat}
> Failed response:
> {
>     "outcome" => "failed",
>     "result" => {
>         "step-1" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-2" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-3" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         }
>     },
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "server-group-A" => {"host" => {
>             "perf31" => {
>                 "perf31-server-3" => "Writes closed",
>                 "perf31-server-5" => "Writes closed"
>             },
>             "perf33" => {"perf33-server-3" => "Writes closed"}
>         }},
>         "server-group-B" => {"host" => {"perf32" => {
>             "perf32-server-2" => "Writes closed",
>             "perf32-server-6" => "Writes closed"
>         }}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "server-group-A" => {"host" => {
>             "perf31" => {
>                 "perf31-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf32" => {
>                 "perf32-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf33" => {
>                 "perf33-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             }
>         }},
>         "server-group-B" => {"host" => {
>             "perf31" => {
>                 "perf31-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf32" => {
>                 "perf32-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf33" => {
>                 "perf33-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             }
>         }}
>     }
> }
> {noformat}
> I know this isn't detailed bug report, I didn't find easy way to reproduce it, other than running large domain tests. Tests are modified tests from https://github.com/wildfly/wildfly/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/suites/DeploymentManagementTestCase.java .
> I can provide other logs, outputs ...., just let me know which log categories would help. 
> Also I tried to play a bit with remoting's HEARTBEAT interval (through subsystem configuration), but that doesn't help. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 10:05:01 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-965) "Writes closed" when
 deploying application in domain
In-Reply-To: <JIRA.12584170.1441634039000@Atlassian.JIRA>
References: <JIRA.12584170.1441634039000@Atlassian.JIRA>
	<JIRA.12584170.1441634039000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584170.1441634039000.8016.1441634701516@Atlassian.JIRA>


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

Tomaz Cerar commented on WFCORE-965:
------------------------------------

Do you maybe have stacktrace that occurs?

> "Writes closed" when deploying application in domain
> ----------------------------------------------------
>
>                 Key: WFCORE-965
>                 URL: https://issues.jboss.org/browse/WFCORE-965
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>         Environment: domain
> profile=default
> 1x domain controller without servers
> 3x slave, 10 servers each
>            Reporter: Martin Simka
>            Assignee: Brian Stansberry
>
> Some of our tests for large domain sometimes fail with error: "Writes closed". It happens only with some higher number of servers per host. 
> {noformat}
> Failed response:
> {
>     "outcome" => "failed",
>     "result" => {
>         "step-1" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-2" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-3" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         }
>     },
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "server-group-A" => {"host" => {
>             "perf31" => {
>                 "perf31-server-3" => "Writes closed",
>                 "perf31-server-5" => "Writes closed"
>             },
>             "perf33" => {"perf33-server-3" => "Writes closed"}
>         }},
>         "server-group-B" => {"host" => {"perf32" => {
>             "perf32-server-2" => "Writes closed",
>             "perf32-server-6" => "Writes closed"
>         }}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "server-group-A" => {"host" => {
>             "perf31" => {
>                 "perf31-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf32" => {
>                 "perf32-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf33" => {
>                 "perf33-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             }
>         }},
>         "server-group-B" => {"host" => {
>             "perf31" => {
>                 "perf31-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf32" => {
>                 "perf32-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf33" => {
>                 "perf33-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             }
>         }}
>     }
> }
> {noformat}
> I know this isn't detailed bug report, I didn't find easy way to reproduce it, other than running large domain tests. Tests are modified tests from https://github.com/wildfly/wildfly/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/suites/DeploymentManagementTestCase.java .
> I can provide other logs, outputs ...., just let me know which log categories would help. 
> Also I tried to play a bit with remoting's HEARTBEAT interval (through subsystem configuration), but that doesn't help. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 10:24:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Sep 2015 10:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.8070.1441635840491@Atlassian.JIRA>


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

Kabir Khan commented on WFLY-5290:
----------------------------------

Here is the output of the variables at
{code}
registerAlias():462, AbstractResourceRegistration {org.jboss.as.controller.registry}
register():209, TransportResourceDefinition {org.jboss.as.clustering.jgroups.subsystem}
register():216, StackResourceDefinition {org.jboss.as.clustering.jgroups.subsystem}
register():122, JGroupsSubsystemResourceDefinition {org.jboss.as.clustering.jgroups.subsystem}
initialize():58, JGroupsExtension {org.jboss.as.clustering.jgroups.subsystem}
initializeExtension():131, ExtensionAddHandler {org.jboss.as.controller.extension}
initializeExtension():104, ExtensionAddHandler {org.jboss.as.controller.extension}
{code}

{code}
this = {ConcreteResourceRegistration at 5356} 
address = {PathElement at 5414} ""transport" => "TRANSPORT""
alias = {SimpleAliasEntry at 5415} 
 target = {ConcreteResourceRegistration at 5357} 
 aliasAddress = {PathAddress at 5459} "[\n    ("profile" => "*"),\n    ("subsystem" => "jgroups"),\n    ("stack" => "*"),\n    ("transport" => "TRANSPORT")\n]"
 targetAddress = {PathAddress at 5418} "[\n    ("profile" => "*"),\n    ("subsystem" => "jgroups"),\n    ("stack" => "*"),\n    ("transport" => "*")\n]"
rootInvocation = {AbstractResourceRegistration$RootInvocation at 5416} 
root = {ConcreteResourceRegistration at 5267} 
myaddr = {PathAddress at 5417} "[\n    ("profile" => "*"),\n    ("subsystem" => "jgroups"),\n    ("stack" => "*")\n]"
targetAddress = {PathAddress at 5418} "[\n    ("profile" => "*"),\n    ("subsystem" => "jgroups"),\n    ("stack" => "*"),\n    ("transport" => "*")\n]"
target = {ConcreteResourceRegistration at 5357} 
{code}

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep  7 11:22:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 7 Sep 2015 11:22:00 -0400 (EDT)
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.8142.1441639320064@Atlassian.JIRA>


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

Jeff Mesnil updated WFLY-4902:
------------------------------
    Summary: Upgrade to Artemis 1.1.0  (was: Upgrade to Artemis 1.0.1)


> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 12:25:00 2015
From: issues at jboss.org (Sarah Julia Kriesch (JIRA))
Date: Mon, 7 Sep 2015 12:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5291) Cache will be cleaned
 automatically with a restart
In-Reply-To: <JIRA.12584182.1441643058000@Atlassian.JIRA>
References: <JIRA.12584182.1441643058000@Atlassian.JIRA>
	<JIRA.12584182.1441643058865@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584182.1441643058000.8176.1441643100089@Atlassian.JIRA>

Sarah Julia Kriesch created WFLY-5291:
-----------------------------------------

             Summary: Cache will be cleaned automatically with a restart
                 Key: WFLY-5291
                 URL: https://issues.jboss.org/browse/WFLY-5291
             Project: WildFly
          Issue Type: Feature Request
          Components: Server
         Environment: for all WildFly Application Servers on every operating system
            Reporter: Sarah Julia Kriesch
            Assignee: Jason Greene
            Priority: Minor


We are using JBoss/ WildFly for our application and have the problem, that you have to shutdown WildFly for clearing the cache.
A full cache is using a lot of performance. Our customers are not happy, if we would have to shutdown the server for cleanings additionally to application hotfixes.

My idea:
A new feature with cleaning the cache (/tmp and /work) automatically with the restart of the application server.  

benefits:
- better performance for the application server
- applications are faster
- lower technical problems with the application
- lower work for the System Administrator
- more place on the hard disk
- customers are happy :-)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 14:37:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 14:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5291) Cache will be cleaned
 automatically with a restart
In-Reply-To: <JIRA.12584182.1441643058000@Atlassian.JIRA>
References: <JIRA.12584182.1441643058000@Atlassian.JIRA>
	<JIRA.12584182.1441643058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584182.1441643058000.8247.1441651020232@Atlassian.JIRA>


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

Tomaz Cerar commented on WFLY-5291:
-----------------------------------

what cashes? Infinispan one? or what?

> Cache will be cleaned automatically with a restart
> --------------------------------------------------
>
>                 Key: WFLY-5291
>                 URL: https://issues.jboss.org/browse/WFLY-5291
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>         Environment: for all WildFly Application Servers on every operating system
>            Reporter: Sarah Julia Kriesch
>            Assignee: Jason Greene
>            Priority: Minor
>
> We are using JBoss/ WildFly for our application and have the problem, that you have to shutdown WildFly for clearing the cache.
> A full cache is using a lot of performance. Our customers are not happy, if we would have to shutdown the server for cleanings additionally to application hotfixes.
> My idea:
> A new feature with cleaning the cache (/tmp and /work) automatically with the restart of the application server.  
> benefits:
> - better performance for the application server
> - applications are faster
> - lower technical problems with the application
> - lower work for the System Administrator
> - more place on the hard disk
> - customers are happy :-)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 15:07:00 2015
From: issues at jboss.org (Sarah Julia Kriesch (JIRA))
Date: Mon, 7 Sep 2015 15:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5291) Cache will be cleaned
 automatically with a restart
In-Reply-To: <JIRA.12584182.1441643058000@Atlassian.JIRA>
References: <JIRA.12584182.1441643058000@Atlassian.JIRA>
	<JIRA.12584182.1441643058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584182.1441643058000.8251.1441652820125@Atlassian.JIRA>


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

Sarah Julia Kriesch commented on WFLY-5291:
-------------------------------------------

I mean */wildfly/standalone/tmp/ *and */wildfly/standalone/tmp/work *, who are the "JBoss cache" in the default language.

> Cache will be cleaned automatically with a restart
> --------------------------------------------------
>
>                 Key: WFLY-5291
>                 URL: https://issues.jboss.org/browse/WFLY-5291
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>         Environment: for all WildFly Application Servers on every operating system
>            Reporter: Sarah Julia Kriesch
>            Assignee: Jason Greene
>            Priority: Minor
>
> We are using JBoss/ WildFly for our application and have the problem, that you have to shutdown WildFly for clearing the cache.
> A full cache is using a lot of performance. Our customers are not happy, if we would have to shutdown the server for cleanings additionally to application hotfixes.
> My idea:
> A new feature with cleaning the cache (/tmp and /work) automatically with the restart of the application server.  
> benefits:
> - better performance for the application server
> - applications are faster
> - lower technical problems with the application
> - lower work for the System Administrator
> - more place on the hard disk
> - customers are happy :-)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 17:22:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Sep 2015 17:22:00 -0400 (EDT)
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.8265.1441660920175@Atlassian.JIRA>


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

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

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1259952|https://bugzilla.redhat.com/show_bug.cgi?id=1259952] from ASSIGNED to NEW

> 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: Jason Greene
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 17:41:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 7 Sep 2015 17:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5291) Cache will be cleaned
 automatically with a restart
In-Reply-To: <JIRA.12584182.1441643058000@Atlassian.JIRA>
References: <JIRA.12584182.1441643058000@Atlassian.JIRA>
	<JIRA.12584182.1441643058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584182.1441643058000.8270.1441662060285@Atlassian.JIRA>


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

Tomaz Cerar commented on WFLY-5291:
-----------------------------------

that two folder do get cleaned up on restart. 
There is feature in VFS to do just that, and another in registration of deployment processors.

In what exact version of WildFly you have problems with that?

> Cache will be cleaned automatically with a restart
> --------------------------------------------------
>
>                 Key: WFLY-5291
>                 URL: https://issues.jboss.org/browse/WFLY-5291
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>         Environment: for all WildFly Application Servers on every operating system
>            Reporter: Sarah Julia Kriesch
>            Assignee: Jason Greene
>            Priority: Minor
>
> We are using JBoss/ WildFly for our application and have the problem, that you have to shutdown WildFly for clearing the cache.
> A full cache is using a lot of performance. Our customers are not happy, if we would have to shutdown the server for cleanings additionally to application hotfixes.
> My idea:
> A new feature with cleaning the cache (/tmp and /work) automatically with the restart of the application server.  
> benefits:
> - better performance for the application server
> - applications are faster
> - lower technical problems with the application
> - lower work for the System Administrator
> - more place on the hard disk
> - customers are happy :-)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 20:12:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 7 Sep 2015 20:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener
 request client certificate despite verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.8283.1441671120239@Atlassian.JIRA>


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

Stuart Douglas commented on WFLY-5256:
--------------------------------------

What is your actual issue here? The title does not match what you have in the description. Is this an issue with certs being requested even though the listener is set to NOT_REQUESTED, or is it an issue with renegotiation not working?

> HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5256
>                 URL: https://issues.jboss.org/browse/WFLY-5256
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Manuel Colchete
>            Assignee: Stuart Douglas
>
> HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access secured resource as first, it don't requested certificate and return HTTP status 403.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 22:50:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 7 Sep 2015 22:50:00 -0400 (EDT)
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.8328.1441680600270@Atlassian.JIRA>


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

Stuart Douglas resolved WFLY-5208.
----------------------------------
    Resolution: Done


The weld listener NPE has been fixed, however the other NPE happens because the deployment is being torn down while the app is still processing requests. There is really nothing we can do about this, and the recommended solution is to use suspend/resume or graceful shutdown. Even if we fixed this NPE there would just be another, and the actual failure you get depends on the application and its workload.

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep  7 23:49:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Sep 2015 23:49:00 -0400 (EDT)
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.8335.1441684140246@Atlassian.JIRA>


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

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

Chao Wang <chaowan at redhat.com> changed the Status of [bug 1259952|https://bugzilla.redhat.com/show_bug.cgi?id=1259952] from NEW to ASSIGNED

> 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: Jason Greene
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 01:07:00 2015
From: issues at jboss.org (Peter Donovans (JIRA))
Date: Tue, 8 Sep 2015 01:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-112) Schema auto generation
 creates columns in alphabetical order for compound primary keys
In-Reply-To: <JIRA.12382463.1237737854000@Atlassian.JIRA>
References: <JIRA.12382463.1237737854000@Atlassian.JIRA>
	<JIRA.12382463.1237737854000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12382463.1237737854000.8343.1441688820220@Atlassian.JIRA>


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

Peter Donovans commented on HIBERNATE-112:
------------------------------------------

I have same issue with JPA2.1 and hibernate embedded into WildFly 9.0.1

But, this link https://docs.jboss.org/hibernate/jpa/2.1/api/javax/persistence/Index.html contains next sentence:
The Index annotation is used in schema generation. Note that it is not necessary to specify an index for a primary key, as the primary key index will be created automatically, *however, the Index annotation may be used to specify the ordering of the columns in the index for the primary key.*

But it not works, hibernate just create primary key with columns sorted alphabetically and additional index with correct columns order. I thinks this is a bug and @Index annotation without name, with column list identical to primary key, should be used for ordering primary key.

> Schema auto generation creates columns in alphabetical order for compound primary keys
> --------------------------------------------------------------------------------------
>
>                 Key: HIBERNATE-112
>                 URL: https://issues.jboss.org/browse/HIBERNATE-112
>             Project: Hibernate Integration
>          Issue Type: Bug
>         Environment: JBoss AS 5.0.1 with EJB3 entities / Hibernate with MySQL Server 5.1
>            Reporter: Jochen Reinhardt
>            Assignee: Steve Ebersole
>
> Schema auto generation creates columns in alphabetical order.
> I would not mind that, but it also affects the creation of primary key indexes. These are rather useless from a database point of view, as the database will only be able to use an index for searching if the columns that are searched for are a prefix of the key. Alphabetical column order is not what one expects. Instead, I would want that my columns are sorted in the same way they appear in my annotated POJO class. I hope I am not missing some simple configuration issue...
> I have a rather complex setup with my entities and relations, using compound primary keys and references. In an entity that maps a complex m:n relationship between two entities with additional properties... Please let me know if you need more details.
> I'm using @Embedded on a primary key class and @EmbeddedId in all my entities.
> I already posted in the Hibernate forums, but I did not get an answer yet, nor did I find any information about my specific problem. The only peace of information I found so far is, that the alphabetical column sort order was introduced because of some issues related to foreign key constraints in clustered environments.  As it is already somewhat urgent, I decided to submit a bug report.
> A colleague of mine found the following in some other forum and I looked up in the source code, too - it's still there. But I do not know if it is correct in general and it only does not work for my setup.
> Cite:
> Hi all,
> I am using EJB3 with hibernate.hbm2ddl.auto=update. I notice the primary keys is been created in database in alphabetic order and not like the order defined at the embedded class. I look at the source code of Hibernate Annotations and found in AnnotationBinder class a Collections.sort at line 1024 with this comment:
> //order so that property are used in the same order when binding native query
> In my project I have primary keys with 4 or 5 fields, and many queries use only 2 ou 3 of them and are running very slow, and the cause was the wrong order of the primary keys in the database.
> I guest that sort is for fixing another bug, but is really annoying, because I need to look each primary key and adjust its order by hand.
> Is there another solution?
> Thanks in advance.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 02:18:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 8 Sep 2015 02:18:00 -0400 (EDT)
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.8354.1441693080176@Atlassian.JIRA>


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

Amos Feng commented on WFLY-5224:
---------------------------------

I wonder why this issue blocks HAL-781. It looks like the unknown attributes 'path' and 'relative' which I think have been removed in WFLY-4445

> 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: Amos Feng
>            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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 02:23:00 2015
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 8 Sep 2015 02:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-761) Not possible to overlay non
 existing file in WAR
In-Reply-To: <JIRA.12575098.1434448130000@Atlassian.JIRA>
References: <JIRA.12575098.1434448130000@Atlassian.JIRA>
	<JIRA.12575098.1434448130000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575098.1434448130000.8358.1441693380160@Atlassian.JIRA>


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

Bartosz Baranowski updated WFCORE-761:
--------------------------------------
    Issue Type: Bug  (was: Feature Request)


> Not possible to overlay non existing file in WAR
> ------------------------------------------------
>
>                 Key: WFCORE-761
>                 URL: https://issues.jboss.org/browse/WFCORE-761
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Bartosz Baranowski
>            Priority: Minor
>
> It is either bug in how deployments are treated or how overlay/vfs work.
> Steps to reproduce:
> 1. deploy undexploded war with jar inside
> 2. add overlay that will add non existing file in jar
> Result: exception:
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt
>     Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}}
>     at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67)
>     at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37)
>     at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76)
>     at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67)
> Expectation:
>  should work. It actually does work, if war is really exploded or
> 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899b2c1109387a0748d925/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java#L117



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 02:48:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 8 Sep 2015 02:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.8385.1441694880128@Atlassian.JIRA>


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

Jan Kalina reassigned ELY-282:
------------------------------

    Assignee: Jan Kalina


> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 03:33:01 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 8 Sep 2015 03:33:01 -0400 (EDT)
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.8455.1441697581643@Atlassian.JIRA>


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

Harald Pehl commented on WFLY-5224:
-----------------------------------

That's true, but while removing the unknown attributes we rewrote the transactions screens to automatically support all available attributes. 

> 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: Amos Feng
>            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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 03:35:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 8 Sep 2015 03:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.8461.1441697700785@Atlassian.JIRA>


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

Jan Kalina commented on ELY-282:
--------------------------------

True, I try take it all.

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 04:21:00 2015
From: issues at jboss.org (Getano Piazzolla (JIRA))
Date: Tue, 8 Sep 2015 04:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-906) Kiescanner do not find
 updates in the KieContainer if the current RELEASE of a maven artifact
 change selecting an older version
In-Reply-To: <JIRA.12584204.1441700444000@Atlassian.JIRA>
References: <JIRA.12584204.1441700444000@Atlassian.JIRA>
	<JIRA.12584204.1441700444029@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584204.1441700444000.8583.1441700460216@Atlassian.JIRA>

Getano Piazzolla created DROOLS-906:
---------------------------------------

             Summary: Kiescanner do not find updates in the KieContainer if the current RELEASE of a maven artifact change selecting an older version
                 Key: DROOLS-906
                 URL: https://issues.jboss.org/browse/DROOLS-906
             Project: Drools
          Issue Type: Bug
    Affects Versions: 6.2.0.Final
         Environment: Ear containing a startup bean, with the kiescanner loaded at postconstruct,
deployed in Wildfly 8.2.0 
            Reporter: Getano Piazzolla
            Assignee: Mark Proctor
            Priority: Critical


When using the KieScanner as indicated in the guide, if the kContainer is initalized using a ReleaseIdImpl that idicate
as version "RELEASE", the KieScanner do not find changes in the repository if we indicate as RELEASE a previous version of the repository.
IN CODE:

ReleaseIdImpl releaseId = new ReleaseIdImpl("blabla", "blabla", "RELEASE");
KieServices ks = KieServices.Factory.get();
kContainer = ks.newKieContainer(releaseId);
kieScanner = ks.newKieScanner(kContainer);
kieScanner.start(5000L);

For example if we change the maven-metadata.xml/maven-metadata-local.xml 

FROM
<metadata>
  <groupId>com.noemalife.dmcs.rules</groupId>
  <artifactId>maven-validation-rules</artifactId>
  <versioning>
    <release>0.2</release>
    <versions>
      <version>0.1</version>
      <version>0.2</version>
    </versions>
    <lastUpdated></lastUpdated>
  </versioning>
</metadata>

TO
<metadata>
  <groupId>com.noemalife.dmcs.rules</groupId>
  <artifactId>maven-validation-rules</artifactId>
  <versioning>
    <release>0.1</release>
    <versions>
      <version>0.1</version>
      <version>0.2</version>
    </versions>
    <lastUpdated></lastUpdated>
  </versioning>
</metadata>

The kieScanner do not find changes; I have to restart the AS to be able to load the correct RELEASE version.
(The kieScanner behaves and updates correctly if I change the release version from 0.1 to 0.2 )




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 04:28:00 2015
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Tue, 8 Sep 2015 04:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Non-functioning 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.8600.1441700880129@Atlassian.JIRA>


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

Pavel Jelinek moved JBEAP-1024 to WFLY-5292:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5292  (was: JBEAP-1024)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Server
                           (was: Web Console)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.Beta2
                           (was: 7.0.0.DR9)


> Non-functioning 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
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Pavel Jelinek
>            Assignee: Heiko Braun
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 04:29:01 2015
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Tue, 8 Sep 2015 04:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Non-functioning 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.8618.1441700941197@Atlassian.JIRA>


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

Pavel Jelinek updated WFLY-5292:
--------------------------------
    Component/s: Web Console


> Non-functioning 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: Heiko Braun
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 04:40:00 2015
From: issues at jboss.org (Chao Wang (JIRA))
Date: Tue, 8 Sep 2015 04:40:00 -0400 (EDT)
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.8653.1441701600444@Atlassian.JIRA>


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

Chao Wang reassigned WFLY-5275:
-------------------------------

    Assignee: Chao Wang  (was: Jason Greene)


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 04:44:00 2015
From: issues at jboss.org (Chao Wang (JIRA))
Date: Tue, 8 Sep 2015 04:44:00 -0400 (EDT)
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.8662.1441701840207@Atlassian.JIRA>


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

Chao Wang commented on WFLY-5275:
---------------------------------

The configuration is not supported, connection-definition common attributes are defined in https://github.com/wildfly/wildfly/blob/master/connector/src/main/resources/schema/wildfly-resource-adapters_3_0.xsd#L183

the workaround is the correct way, although, we should throw XMLStreamException with informative message for such unexpected attribute inside "connection-definition".

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 04:55:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 8 Sep 2015 04:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-907) Add team page on
 kiegroup.org that links to the team pages of drools,
 jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses
 requests)
In-Reply-To: <JIRA.12584206.1441702460000@Atlassian.JIRA>
References: <JIRA.12584206.1441702460000@Atlassian.JIRA>
	<JIRA.12584206.1441702460643@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584206.1441702460000.8676.1441702500358@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-907:
---------------------------------------

             Summary: Add team page on kiegroup.org that links to the team pages of drools, jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses requests)
                 Key: DROOLS-907
                 URL: https://issues.jboss.org/browse/DROOLS-907
             Project: Drools
          Issue Type: Enhancement
            Reporter: Geoffrey De Smet
            Assignee: Michael Biarnes Kiefer


Add a team page for the kiegroup website
  http://www.kiegroup.org/
that links to these 3 pages:
  http://www.drools.org/community/team.html
  http://www.optaplanner.org/community/team.html
  http://www.jbpm.org/community/team.html




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 05:49:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 8 Sep 2015 05:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-761) Not possible to overlay non
 existing file in WAR
In-Reply-To: <JIRA.12575098.1434448130000@Atlassian.JIRA>
References: <JIRA.12575098.1434448130000@Atlassian.JIRA>
	<JIRA.12575098.1434448130000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575098.1434448130000.9069.1441705740125@Atlassian.JIRA>


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

Stuart Douglas reassigned WFCORE-761:
-------------------------------------

    Assignee: Stuart Douglas


> Not possible to overlay non existing file in WAR
> ------------------------------------------------
>
>                 Key: WFCORE-761
>                 URL: https://issues.jboss.org/browse/WFCORE-761
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Bartosz Baranowski
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> It is either bug in how deployments are treated or how overlay/vfs work.
> Steps to reproduce:
> 1. deploy undexploded war with jar inside
> 2. add overlay that will add non existing file in jar
> Result: exception:
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt
>     Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}}
>     at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67)
>     at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37)
>     at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76)
>     at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67)
> Expectation:
>  should work. It actually does work, if war is really exploded or
> 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899b2c1109387a0748d925/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java#L117



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 06:01:02 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Sep 2015 06:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-468) Allow --rollback-to with
 cumulative patches
In-Reply-To: <JIRA.12545845.1404823612000@Atlassian.JIRA>
References: <JIRA.12545845.1404823612000@Atlassian.JIRA>
	<JIRA.12545845.1404823612000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545845.1404823612000.9182.1441706462407@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFCORE-468:
------------------------------------------------

Enrique Gonzalez Martinez <egonzale at redhat.com> changed the Status of [bug 1117317|https://bugzilla.redhat.com/show_bug.cgi?id=1117317] from NEW to CLOSED

> Allow --rollback-to with cumulative patches
> -------------------------------------------
>
>                 Key: WFCORE-468
>                 URL: https://issues.jboss.org/browse/WFCORE-468
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Patching 
>    Affects Versions: 1.0.0.Alpha1
>            Reporter: Martin Simka
>            Assignee: Alexey Loubyansky
>
> patch --rollback-to currently works only with one-off patches, it would be beneficial if this would work with cumulative patches too. 
> Please be aware of WFLY-3597, it is for highlighting information that --rollback-to is specific to one-off patches. At least one of these two jiras should be implemented.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 06:15:03 2015
From: issues at jboss.org (Arto Huusko (JIRA))
Date: Tue, 8 Sep 2015 06:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5293) EJB3 method invocation
 statistics exposed incorrectly through JMX
In-Reply-To: <JIRA.12584218.1441707247000@Atlassian.JIRA>
References: <JIRA.12584218.1441707247000@Atlassian.JIRA>
	<JIRA.12584218.1441707247386@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584218.1441707247000.9292.1441707303627@Atlassian.JIRA>

Arto Huusko created WFLY-5293:
---------------------------------

             Summary: EJB3 method invocation statistics exposed incorrectly through JMX
                 Key: WFLY-5293
                 URL: https://issues.jboss.org/browse/WFLY-5293
             Project: WildFly
          Issue Type: Bug
          Components: JMX
    Affects Versions: 9.0.1.Final
            Reporter: Arto Huusko
            Assignee: Kabir Khan


EJB3 method invocation statistics, that is the "methods" attribute in an EJB3 session JMX object is exposed as CompositeDataSupport object that has the expected keys ("execution-time", and so on), but

- the values for the keys are always null
- there is only a single CompositeDataSupport object even when the session has several methods
- the method name is not available.

Possibly the invocation statistics should be exposed as an array of CompositeDataSupport objects where one of the keys is the method name.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 06:32:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 8 Sep 2015 06:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5294) Upgrade HAL to 2.8.8
In-Reply-To: <JIRA.12584219.1441708288000@Atlassian.JIRA>
References: <JIRA.12584219.1441708288000@Atlassian.JIRA>
	<JIRA.12584219.1441708288348@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584219.1441708288000.9379.1441708320467@Atlassian.JIRA>

Tomas Hofman created WFLY-5294:
----------------------------------

             Summary: Upgrade HAL to 2.8.8
                 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 06:32:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 8 Sep 2015 06:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5294) Upgrade HAL to 2.8.8
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.9382.1441708320535@Atlassian.JIRA>


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

Tomas Hofman updated WFLY-5294:
-------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/8058)


> Upgrade HAL to 2.8.8
> --------------------
>
>                 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 07:02:00 2015
From: issues at jboss.org (Martin Simka (JIRA))
Date: Tue, 8 Sep 2015 07:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-965) "Writes closed" when
 deploying application in domain
In-Reply-To: <JIRA.12584170.1441634039000@Atlassian.JIRA>
References: <JIRA.12584170.1441634039000@Atlassian.JIRA>
	<JIRA.12584170.1441634039000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584170.1441634039000.9582.1441710120307@Atlassian.JIRA>


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

Martin Simka commented on WFCORE-965:
-------------------------------------

stacktrace from one of slaves
{noformat}
2015-09-08 06:47:23,049 DEBUG [org.jboss.as.protocol] (Host Controller Service Threads - 124) active-op (1367836977) failed org.jboss.as.controller.remote.TransactionalProtocolClientImpl$ExecuteRequestContext at 541c0a2: org.jboss.remoting3.NotOpenException: Writes closed
        at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:117)
        at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:306)
        at org.jboss.as.protocol.mgmt.AbstractMessageHandler$1.writeMessage(AbstractMessageHandler.java:214)
        at org.jboss.as.protocol.mgmt.AbstractManagementRequest.sendRequest(AbstractManagementRequest.java:51)
        at org.jboss.as.controller.remote.TransactionalProtocolClientImpl$CompleteTxRequest.sendRequestInternal(TransactionalProtocolClientImpl.java:290)
        at org.jboss.as.controller.remote.TransactionalProtocolClientImpl$CompleteTxRequest.access$500(TransactionalProtocolClientImpl.java:242)
        at org.jboss.as.controller.remote.TransactionalProtocolClientImpl$CompleteTxRequest$1.execute(TransactionalProtocolClientImpl.java:264)
        at org.jboss.as.protocol.mgmt.AbstractMessageHandler$1$1.doExecute(AbstractMessageHandler.java:176)
        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}

> "Writes closed" when deploying application in domain
> ----------------------------------------------------
>
>                 Key: WFCORE-965
>                 URL: https://issues.jboss.org/browse/WFCORE-965
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>         Environment: domain
> profile=default
> 1x domain controller without servers
> 3x slave, 10 servers each
>            Reporter: Martin Simka
>            Assignee: Brian Stansberry
>
> Some of our tests for large domain sometimes fail with error: "Writes closed". It happens only with some higher number of servers per host. 
> {noformat}
> Failed response:
> {
>     "outcome" => "failed",
>     "result" => {
>         "step-1" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-2" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-3" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         }
>     },
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "server-group-A" => {"host" => {
>             "perf31" => {
>                 "perf31-server-3" => "Writes closed",
>                 "perf31-server-5" => "Writes closed"
>             },
>             "perf33" => {"perf33-server-3" => "Writes closed"}
>         }},
>         "server-group-B" => {"host" => {"perf32" => {
>             "perf32-server-2" => "Writes closed",
>             "perf32-server-6" => "Writes closed"
>         }}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "server-group-A" => {"host" => {
>             "perf31" => {
>                 "perf31-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf32" => {
>                 "perf32-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf33" => {
>                 "perf33-server-1" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-3" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-5" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-7" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-9" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             }
>         }},
>         "server-group-B" => {"host" => {
>             "perf31" => {
>                 "perf31-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf31-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf32" => {
>                 "perf32-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => undefined,
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => undefined,
>                     "failure-description" => "Writes closed",
>                     "rolled-back" => true
>                 }},
>                 "perf32-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             },
>             "perf33" => {
>                 "perf33-server-10" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-2" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-4" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-6" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }},
>                 "perf33-server-8" => {"response" => {
>                     "outcome" => "failed",
>                     "result" => {"step-1" => {
>                         "outcome" => "failed",
>                         "rolled-back" => true
>                     }},
>                     "failure-description" => "WFLYCTL0063: Composite operation was rolled back",
>                     "rolled-back" => true
>                 }}
>             }
>         }}
>     }
> }
> {noformat}
> I know this isn't detailed bug report, I didn't find easy way to reproduce it, other than running large domain tests. Tests are modified tests from https://github.com/wildfly/wildfly/blob/master/testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/suites/DeploymentManagementTestCase.java .
> I can provide other logs, outputs ...., just let me know which log categories would help. 
> Also I tried to play a bit with remoting's HEARTBEAT interval (through subsystem configuration), but that doesn't help. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 07:26:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Sep 2015 07:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Non-functioning 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.9694.1441711560206@Atlassian.JIRA>


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

Heiko Braun reassigned WFLY-5292:
---------------------------------

    Assignee: Brian Stansberry  (was: Heiko Braun)


> Non-functioning 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: Brian Stansberry
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 08:25:00 2015
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Tue, 8 Sep 2015 08:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5295) In domain mode non existing
 subhandler is saved to attributes.
In-Reply-To: <JIRA.12583440.1441114363000@Atlassian.JIRA>
References: <JIRA.12583440.1441114363000@Atlassian.JIRA>
	<JIRA.12583440.1441114363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583440.1441114363000.9920.1441715100195@Atlassian.JIRA>


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

Pavel Jelinek moved HAL-819 to WFLY-5295:
-----------------------------------------

               Project: WildFly  (was: HAL)
                   Key: WFLY-5295  (was: HAL-819)
            Issue Type: Bug  (was: Feature Request)
              Workflow: GIT Pull Request workflow   (was: classic default workflow)
           Component/s: Logging
                            (was: Subsystem Configuration)
    Steps to Reproduce: 
1.Run EAP in domain mode (default profile)
2.Create async handler
3.Try to add non existing subhandler to async handler attributes
4.Try the same in standalone mode with standalone-full-ha profile


> In domain mode non existing subhandler is saved to attributes.
> --------------------------------------------------------------
>
>                 Key: WFLY-5295
>                 URL: https://issues.jboss.org/browse/WFLY-5295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>         Environment: Running unsecured EAP 7.0.0 DR9 version in domain mode.
>            Reporter: Patrik Cyprian
>            Assignee: Heiko Braun
>
> When you in domain mode in created async handler add non existing sub handler to attributes it is successfully saved. In standalone mode it is not possible (subhandler is not saved - saving operation failed).
> 1.Run EAP in domain mode (default profile)
> 2.Create async handler
> 3.Try to add non existing subhandler to async handler attributes
> 4.Try the same in standalone mode with standalone-full-ha profile



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 08:26:00 2015
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Tue, 8 Sep 2015 08:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5295) In domain mode non existing
 subhandler is saved to attributes.
In-Reply-To: <JIRA.12583440.1441114363000@Atlassian.JIRA>
References: <JIRA.12583440.1441114363000@Atlassian.JIRA>
	<JIRA.12583440.1441114363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583440.1441114363000.9934.1441715160725@Atlassian.JIRA>


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

Pavel Jelinek reopened WFLY-5295:
---------------------------------
      Assignee: James Perkins  (was: Heiko Braun)


According to the last comment it's subsystem issue.

> In domain mode non existing subhandler is saved to attributes.
> --------------------------------------------------------------
>
>                 Key: WFLY-5295
>                 URL: https://issues.jboss.org/browse/WFLY-5295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>         Environment: Running unsecured EAP 7.0.0 DR9 version in domain mode.
>            Reporter: Patrik Cyprian
>            Assignee: James Perkins
>
> When you in domain mode in created async handler add non existing sub handler to attributes it is successfully saved. In standalone mode it is not possible (subhandler is not saved - saving operation failed).
> 1.Run EAP in domain mode (default profile)
> 2.Create async handler
> 3.Try to add non existing subhandler to async handler attributes
> 4.Try the same in standalone mode with standalone-full-ha profile



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 08:43:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Sep 2015 08:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Non-functioning 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.9975.1441716180365@Atlassian.JIRA>


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

Darran Lofthouse reassigned WFLY-5292:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)


> Non-functioning 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 08:58:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Sep 2015 08:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Non-functioning 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.10045.1441717080259@Atlassian.JIRA>


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

Darran Lofthouse resolved WFLY-5292.
------------------------------------
    Fix Version/s: 10.0.0.CR1
       Resolution: Rejected


Just double checked and WildFly 10 is working as expected, the following error is displayed: -

_No Console Active

The server configuration does not appear to have an active console. If you are running a standalone server check the http interface is enabled in the standalone.xml configuration, if you are running a domain the http interface can not be automatically detected so check the host.xml configuration and connect directly._

The title of this issues says 'Non-functioning link' with no description as to what non-functioning means.  Redirecting to the above error message is the correct function of that link in domain mode.


> Non-functioning 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 09:13:00 2015
From: issues at jboss.org (Andreas Liebscher (JIRA))
Date: Tue, 8 Sep 2015 09:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5296) public final methods should
 be allowed for Local and Remote Business Interface View
In-Reply-To: <JIRA.12584249.1441717948000@Atlassian.JIRA>
References: <JIRA.12584249.1441717948000@Atlassian.JIRA>
	<JIRA.12584249.1441717948361@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584249.1441717948000.10125.1441717980338@Atlassian.JIRA>

Andreas Liebscher created WFLY-5296:
---------------------------------------

             Summary: public final methods should be allowed for Local and Remote Business Interface View
                 Key: WFLY-5296
                 URL: https://issues.jboss.org/browse/WFLY-5296
             Project: WildFly
          Issue Type: Bug
          Components: EE
    Affects Versions: 9.0.1.Final
            Reporter: Andreas Liebscher


The spec says:
Only public methods of the bean class (and any superclasses) may be invoked through the no-interface view. Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException.

So it is not allowed to use public final methods when using no-interface view.

But WF-9.0.1-Final does also throw an exception when using local business interface view:
 ERROR [org.jboss.as.ejb3.invocation] (default task-31) WFLYEJB0034: EJB Invocation failed on component XxxBean for method public abstract yyy: javax.ejb.EJBException: java.lang.IllegalStateException: WFLYEE0067: Method does not exist public final zzz

With WF-8.1.0-Final this was no problem!
What has been changed in WF-9?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 09:13:00 2015
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Tue, 8 Sep 2015 09:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Non-functioning 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.10128.1441717980443@Atlassian.JIRA>


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

Pavel Jelinek commented on WFLY-5292:
-------------------------------------

I'm not sure if all user will read the whole text to find out that 'No console active' means that there may be (and probably really is) active console but in domain mode it just can not be automatically detected.

> Non-functioning 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 09:14:00 2015
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Tue, 8 Sep 2015 09:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Non-functioning 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.10131.1441718040183@Atlassian.JIRA>


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

Pavel Jelinek edited comment on WFLY-5292 at 9/8/15 9:13 AM:
-------------------------------------------------------------

I'm not sure if all user will read the whole text to find out that 'No console active' means that there may be (and probably really is) active console but it just can not be automatically detected in domain mode.


was (Author: pjelinek):
I'm not sure if all user will read the whole text to find out that 'No console active' means that there may be (and probably really is) active console but in domain mode it just can not be automatically detected.

> Non-functioning 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 09:17:00 2015
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Tue, 8 Sep 2015 09:17:00 -0400 (EDT)
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.10142.1441718220232@Atlassian.JIRA>


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

Pavel Jelinek updated WFLY-5292:
--------------------------------
    Summary: Missleading link to console from Wildfly10 homepage in domain mode  (was: Non-functioning link to console from Wildfly10 homepage in domain mode)


> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 09:49:02 2015
From: issues at jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 8 Sep 2015 09:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Enable SPNEGO Authentication
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.10274.1441720142368@Atlassian.JIRA>


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

Dimitris Andreadis updated WFLY-2553:
-------------------------------------
    Comment: was deleted

(was: 


ECCLESIA Clerk
Server: Ibis

-----------------------------------------------------------------------
Andreas Kind
Sehr geehrte Damen und Herren, ich bin bis zum 28.07.2015 einschlie?lich
nicht erreichbar. Ihre E-Mail wird bis dahin archiviert. Mit freundlichen
Gr??en,



)


> Enable SPNEGO Authentication
> ----------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep  8 09:49:02 2015
From: issues at jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 8 Sep 2015 09:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Enable SPNEGO Authentication
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.10302.1441720142975@Atlassian.JIRA>


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

Dimitris Andreadis updated WFLY-2553:
-------------------------------------
    Comment: was deleted

(was: 


ECCLESIA Clerk
Server: Ibis

-----------------------------------------------------------------------
Andreas Kind
Sehr geehrte Damen und Herren, ich bin bis zum 31.05.2015 einschlie?lich
nicht erreichbar. Ihre E-Mail wird bis dahin archiviert. Mit freundlichen
Gr??en,



)


> Enable SPNEGO Authentication
> ----------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep  8 09:49:03 2015
From: issues at jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 8 Sep 2015 09:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Enable SPNEGO Authentication
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.10330.1441720143618@Atlassian.JIRA>


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

Dimitris Andreadis updated WFLY-2553:
-------------------------------------
    Comment: was deleted

(was: 


ECCLESIA Clerk
Server: Ibis

-----------------------------------------------------------------------
Andreas Kind
Sehr geehrte Damen und Herren, ich bin bis zum 06.04.2015 einschlie?lich
nicht erreichbar. Ihre E-Mail wird bis dahin archiviert. Mit freundlichen
Gr??en,



)


> Enable SPNEGO Authentication
> ----------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep  8 09:49:04 2015
From: issues at jboss.org (Dimitris Andreadis (JIRA))
Date: Tue, 8 Sep 2015 09:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Enable SPNEGO Authentication
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.10358.1441720144225@Atlassian.JIRA>


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

Dimitris Andreadis updated WFLY-2553:
-------------------------------------
    Comment: was deleted

(was: 


ECCLESIA Clerk
Server: Ibis

-----------------------------------------------------------------------
Andreas Kind
Sehr geehrte Damen und Herren, ich bin bis zum 31.05.2015 einschlie?lich
nicht erreichbar. Ihre E-Mail wird bis dahin archiviert. Mit freundlichen
Gr??en,



)


> Enable SPNEGO Authentication
> ----------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep  8 10:14:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Sep 2015 10:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Enable SPNEGO Authentication
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.10571.1441721641559@Atlassian.JIRA>


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

Darran Lofthouse updated WFLY-2553:
-----------------------------------
        Parent:     (was: WFLY-2552)
    Issue Type: Feature Request  (was: Sub-task)


> Enable SPNEGO Authentication
> ----------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 10:15:03 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Sep 2015 10:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Support for SPNEGO
 authentication for deployed web applications
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.10599.1441721703476@Atlassian.JIRA>


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

Darran Lofthouse updated WFLY-2553:
-----------------------------------
    Summary: Support for SPNEGO authentication for deployed web applications  (was: Enable SPNEGO Authentication)


> Support for SPNEGO authentication for deployed web applications
> ---------------------------------------------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 10:15:04 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Sep 2015 10:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Support for SPNEGO
 authentication for deployed web applications
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.10628.1441721704185@Atlassian.JIRA>


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

Darran Lofthouse updated WFLY-2553:
-----------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Support for SPNEGO authentication for deployed web applications
> ---------------------------------------------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 10:29:00 2015
From: issues at jboss.org (Martin Styk (JIRA))
Date: Tue, 8 Sep 2015 10:29:00 -0400 (EDT)
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.10696.1441722540132@Atlassian.JIRA>


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

Martin Styk updated WFLY-5142:
------------------------------
    Component/s: Documentation


> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 10:49:00 2015
From: issues at jboss.org (Martin Styk (JIRA))
Date: Tue, 8 Sep 2015 10:49:00 -0400 (EDT)
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.10914.1441723740367@Atlassian.JIRA>


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

Martin Styk commented on WFLY-5142:
-----------------------------------

If you want unauthenticated identity to be considered as a "guest", your standalone-full...xml should contain <module-option name="unauthenticatedIdentity" value="guest"/> in <login-module code="RealmDirect" flag="required">

{noformat}
 <subsystem xmlns="urn:jboss:domain:security:1.2">
            <security-domains>
                <security-domain name="other" cache-type="default">
                    <authentication>
                        ...
                        <login-module code="RealmDirect" flag="required">
                           ... 
                           <module-option name="unauthenticatedIdentity" value="guest"/>
                            ...
                        </login-module>
                     ...
                    </authentication>
                </security-domain>
               ...
        </subsystem>
{noformat}

> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 10:53:00 2015
From: issues at jboss.org (Martin Styk (JIRA))
Date: Tue, 8 Sep 2015 10:53:00 -0400 (EDT)
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.10959.1441723980847@Atlassian.JIRA>


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

Martin Styk edited comment on WFLY-5142 at 9/8/15 10:52 AM:
------------------------------------------------------------

If you want unauthenticated identity to be considered as a "guest", your standalone-full...xml should contain <module-option name="unauthenticatedIdentity" value="guest"/> in <login-module code="RealmDirect" flag="required">

{noformat}
 <subsystem xmlns="urn:jboss:domain:security:1.2">
            <security-domains>
                <security-domain name="other" cache-type="default">
                    <authentication>
                        ...
                        <login-module code="RealmDirect" flag="required">
                           ... 
                           <module-option name="unauthenticatedIdentity" value="guest"/>
                            ...
                        </login-module>
                     ...
                    </authentication>
                </security-domain>
               ...
           </security-domains>
 </subsystem>
{noformat}


was (Author: mstyk):
If you want unauthenticated identity to be considered as a "guest", your standalone-full...xml should contain <module-option name="unauthenticatedIdentity" value="guest"/> in <login-module code="RealmDirect" flag="required">

{noformat}
 <subsystem xmlns="urn:jboss:domain:security:1.2">
            <security-domains>
                <security-domain name="other" cache-type="default">
                    <authentication>
                        ...
                        <login-module code="RealmDirect" flag="required">
                           ... 
                           <module-option name="unauthenticatedIdentity" value="guest"/>
                            ...
                        </login-module>
                     ...
                    </authentication>
                </security-domain>
               ...
        </subsystem>
{noformat}

> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 10:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 10:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-708) Need to configure JAAS for
 host controller in host.xml
In-Reply-To: <JIRA.12527987.1387178413000@Atlassian.JIRA>
References: <JIRA.12527987.1387178413000@Atlassian.JIRA>
	<JIRA.12527987.1387178413000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527987.1387178413000.11026.1441724340469@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-708:
---------------------------------------

    Assignee:     (was: Brian Stansberry)


> Need to configure JAAS for host controller in host.xml
> ------------------------------------------------------
>
>                 Key: WFCORE-708
>                 URL: https://issues.jboss.org/browse/WFCORE-708
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Hisanobu Okuda
>
> I want to configure an advanced authentication for host controller as follow:-
> (1) perform authentication against LDAP
> (2) if (1) fails, perform authentication against properties file
> To do this in domain mode, I need to set up a legacy JAAS config file and specify it via java.security.auth.login.config system property. It spoils maintainability and security of EAP6 in terms of:-
> 1. unable to maintain it using jboss-cli.sh
> 2. unable to use the vault feature for it



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 11:00:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 11:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.11050.1441724402096@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-756:
---------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 11:43:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-885) World readable audit.log file
In-Reply-To: <JIRA.12581568.1439814262000@Atlassian.JIRA>
References: <JIRA.12581568.1439814262000@Atlassian.JIRA>
	<JIRA.12581568.1439814262000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581568.1439814262000.11539.1441726980481@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-885:
---------------------------------------

    Assignee: Ivo Studensky  (was: Brian Stansberry)


> World readable audit.log file
> -----------------------------
>
>                 Key: WFCORE-885
>                 URL: https://issues.jboss.org/browse/WFCORE-885
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta2
>            Reporter: Ondrej Lukas
>            Assignee: Ivo Studensky
>            Priority: Blocker
>             Fix For: 2.0.0.Beta6
>
>
> Server logs sensitive information into a world readable audit.log file. This information could be used by a local attacker to gain otherwise protected information about user sessions etc.
> This issue was originally reported as CVE in https://bugzilla.redhat.com/show_bug.cgi?id=1063642. EAP 6.x branches are fixed but same issue occurs in EAP 7 again.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 12:04:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 12:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-939) Embedded host controller
 should set launch type attribute to EMBEDDED
In-Reply-To: <JIRA.12583251.1441022081000@Atlassian.JIRA>
References: <JIRA.12583251.1441022081000@Atlassian.JIRA>
	<JIRA.12583251.1441022081000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583251.1441022081000.11731.1441728240208@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-939:
-----------------------------------------

Using ServerEnvironment.LaunchType to drive this attribute in the first place was incorrect IMO. If you look at the full use of the enum, it's clearly not related to HC processes.

Using "DOMAIN" for the standard non-embedded case isn't an ideal term, but since that's what we've reported in the past we should stick with that even if we change the enum to something HC-specific.

> Embedded host controller should set launch type attribute to EMBEDDED
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-939
>                 URL: https://issues.jboss.org/browse/WFCORE-939
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>
> *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded. 
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
>     /** The manner in which a server can be launched */
>     public static enum LaunchType {
>         /** Launched by a Host Controller in a managed domain */
>         DOMAIN(ProcessType.DOMAIN_SERVER),
>         /** Launched from the command line */
>         STANDALONE(ProcessType.STANDALONE_SERVER),
>         /** Launched by another process in which the server is embedded */
>         EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type              STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type              DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server 
> launch-type              EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type              DOMAIN
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 12:19:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 8 Sep 2015 12:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-966) In domain mode non existing
 subhandler is saved to attributes.
In-Reply-To: <JIRA.12583440.1441114363000@Atlassian.JIRA>
References: <JIRA.12583440.1441114363000@Atlassian.JIRA>
	<JIRA.12583440.1441114363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583440.1441114363000.11854.1441729140460@Atlassian.JIRA>


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

James Perkins moved WFLY-5295 to WFCORE-966:
--------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-966  (was: WFLY-5295)
    Component/s: Logging
                     (was: Logging)


> In domain mode non existing subhandler is saved to attributes.
> --------------------------------------------------------------
>
>                 Key: WFCORE-966
>                 URL: https://issues.jboss.org/browse/WFCORE-966
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>         Environment: Running unsecured EAP 7.0.0 DR9 version in domain mode.
>            Reporter: Patrik Cyprian
>            Assignee: James Perkins
>
> When you in domain mode in created async handler add non existing sub handler to attributes it is successfully saved. In standalone mode it is not possible (subhandler is not saved - saving operation failed).
> 1.Run EAP in domain mode (default profile)
> 2.Create async handler
> 3.Try to add non existing subhandler to async handler attributes
> 4.Try the same in standalone mode with standalone-full-ha profile



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 12:33:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 8 Sep 2015 12:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4515) Fix clustering transformers
 and reenable in mixed-domain tests
In-Reply-To: <JIRA.12568394.1429024821000@Atlassian.JIRA>
References: <JIRA.12568394.1429024821000@Atlassian.JIRA>
	<JIRA.12568394.1429024821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568394.1429024821000.11932.1441729980410@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-4515:
--------------------------------------

The minimal list with current issues is

a) some children are implicitly added, so its not possible to easily decide whether to reject or discard 
solution: could be maybe done by a custom discard policy and iterating over the attributes

b) org.jboss.as.controller.transform.description.RejectAttributeChecker#rejectResourceAttribute is called with address of the legacy resource, so its not possible to do context.readResourceFromRoot(address).getModel() (fails with no child)
solution: 
{noformat}
-        return this.rejecter.reject(address, name, value, context.readResourceFromRoot(address).getModel(), context);
+        return this.rejecter.reject(address, name, value, context.readResource(PathAddress.EMPTY_ADDRESS).getModel(), context);
{noformat}

c) replicat properties trasnformation from jgroups subsystem, however, only once custom resource transformer can be registered and there are already some registered
wip

d) java.lang.AssertionError: cache-container/maximal/distributed-cache/dist/eviction/EVICTION/max-entries/ types expected:<INT> but was:<LONG>
wip

> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
>                 Key: WFLY-4515
>                 URL: https://issues.jboss.org/browse/WFLY-4515
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Kabir Khan
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. 
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> 	mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
>    ("profile" => "full-ha"),
>    ("subsystem" => "infinispan"),
>    ("cache-container" => "server"),
>    ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> 	/subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ThreadsAttributesWriteHandler.java#L61 so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 12:46:01 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 8 Sep 2015 12:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4515) Fix clustering transformers
 and reenable in mixed-domain tests
In-Reply-To: <JIRA.12568394.1429024821000@Atlassian.JIRA>
References: <JIRA.12568394.1429024821000@Atlassian.JIRA>
	<JIRA.12568394.1429024821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568394.1429024821000.11977.1441730761146@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-4515:
--------------------------------------

  TransformersTestCase.testTransformer640:140->testTransformation:170->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/minimal/local-cache/local/transaction/TRANSACTION/stop-timeout/ types expected:<LONG> but was:<INT>

> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
>                 Key: WFLY-4515
>                 URL: https://issues.jboss.org/browse/WFLY-4515
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Kabir Khan
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. 
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> 	mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
>    ("profile" => "full-ha"),
>    ("subsystem" => "infinispan"),
>    ("cache-container" => "server"),
>    ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> 	/subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ThreadsAttributesWriteHandler.java#L61 so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 12:54:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Sep 2015 12:54:00 -0400 (EDT)
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.12015.1441731240187@Atlassian.JIRA>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1257612|https://bugzilla.redhat.com/show_bug.cgi?id=1257612] from POST to MODIFIED

> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 13:58:00 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 8 Sep 2015 13:58:00 -0400 (EDT)
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.1441735040187@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584300.1441735040000.12127.1441735080253@Atlassian.JIRA>

Jesper Pedersen created WFLY-5297:
-------------------------------------

             Summary: 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.CR2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 14:38:00 2015
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 8 Sep 2015 14:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-259) Be able to configure the
 callback handlers used for Sasl Entity
In-Reply-To: <JIRA.12580528.1438877447000@Atlassian.JIRA>
References: <JIRA.12580528.1438877447000@Atlassian.JIRA>
	<JIRA.12580528.1438877447000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580528.1438877447000.12246.1441737480228@Atlassian.JIRA>


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

Farah Juma reassigned ELY-259:
------------------------------

    Assignee: Farah Juma  (was: Darran Lofthouse)


> Be able to configure the callback handlers used for Sasl Entity
> ---------------------------------------------------------------
>
>                 Key: ELY-259
>                 URL: https://issues.jboss.org/browse/ELY-259
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Kabir Khan
>            Assignee: Farah Juma
>             Fix For: 1.1.0.Alpha1
>
>
> We need to be able to configure VerifyPeerTrustedCallback, CredentialCallback (for X509Certificate and PrivateKey) and TrustedAuthoritiesCallback on the client and on the server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 14:42:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 8 Sep 2015 14:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.12262.1441737720114@Atlassian.JIRA>


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

ehsavoie Hugonnet commented on WFCORE-949:
------------------------------------------

Fixing by setting the server into reload-required mode to stop the socket effectively on reload.

> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: ehsavoie Hugonnet
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 15:51:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Sep 2015 15:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-967) list-xxx and map-xxx do not
 work in a composite
In-Reply-To: <JIRA.12584305.1441741810000@Atlassian.JIRA>
References: <JIRA.12584305.1441741810000@Atlassian.JIRA>
	<JIRA.12584305.1441741810958@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584305.1441741810000.12454.1441741860347@Atlassian.JIRA>

Kabir Khan created WFCORE-967:
---------------------------------

             Summary: list-xxx and map-xxx do not work in a composite
                 Key: WFCORE-967
                 URL: https://issues.jboss.org/browse/WFCORE-967
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta6
            Reporter: Kabir Khan
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR1


When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
{code}
Model Before: {
    "deployment" => undefined,
    "subsystem" => {"test-subsystem" => {
        "properties" => {
            "one" => "A",
            "two" => "B",
            "three" => "C"
        },
        "test" => "Hello"
    }}
}
{
    "operation" => "composite",
    "address" => [],
    "steps" => [
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "one"
        },
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "two"
        },
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "three"
        }
    ]
}
Model After: {
    "deployment" => undefined,
    "subsystem" => {"test-subsystem" => {
        "properties" => {
            "one" => "A",
            "two" => "B"
        },
        "test" => "Hello"
    }}
}
{code}
The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demostrate the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 15:51:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Sep 2015 15:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-967) list-xxx and map-xxx do not
 work in a composite
In-Reply-To: <JIRA.12584305.1441741810000@Atlassian.JIRA>
References: <JIRA.12584305.1441741810000@Atlassian.JIRA>
	<JIRA.12584305.1441741810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584305.1441741810000.12458.1441741860453@Atlassian.JIRA>


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

Kabir Khan updated WFCORE-967:
------------------------------
    Priority: Critical  (was: Major)


> list-xxx and map-xxx do not work in a composite
> -----------------------------------------------
>
>                 Key: WFCORE-967
>                 URL: https://issues.jboss.org/browse/WFCORE-967
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
> {code}
> Model Before: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B",
>             "three" => "C"
>         },
>         "test" => "Hello"
>     }}
> }
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "one"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "two"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "three"
>         }
>     ]
> }
> Model After: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B"
>         },
>         "test" => "Hello"
>     }}
> }
> {code}
> The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demostrate the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 15:52:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Sep 2015 15:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-967) list-xxx and map-xxx do not
 work in a composite
In-Reply-To: <JIRA.12584305.1441741810000@Atlassian.JIRA>
References: <JIRA.12584305.1441741810000@Atlassian.JIRA>
	<JIRA.12584305.1441741810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584305.1441741810000.12467.1441741920390@Atlassian.JIRA>


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

Tomaz Cerar reassigned WFCORE-967:
----------------------------------

    Assignee: Tomaz Cerar  (was: Brian Stansberry)


> list-xxx and map-xxx do not work in a composite
> -----------------------------------------------
>
>                 Key: WFCORE-967
>                 URL: https://issues.jboss.org/browse/WFCORE-967
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>            Reporter: Kabir Khan
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
> {code}
> Model Before: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B",
>             "three" => "C"
>         },
>         "test" => "Hello"
>     }}
> }
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "one"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "two"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "three"
>         }
>     ]
> }
> Model After: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B"
>         },
>         "test" => "Hello"
>     }}
> }
> {code}
> The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demostrate the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 15:52:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Sep 2015 15:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-967) list-xxx and map-xxx do not
 work in a composite
In-Reply-To: <JIRA.12584305.1441741810000@Atlassian.JIRA>
References: <JIRA.12584305.1441741810000@Atlassian.JIRA>
	<JIRA.12584305.1441741810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584305.1441741810000.12471.1441741920526@Atlassian.JIRA>


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

Kabir Khan updated WFCORE-967:
------------------------------
    Description: 
When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
{code}
Model Before: {
    "deployment" => undefined,
    "subsystem" => {"test-subsystem" => {
        "properties" => {
            "one" => "A",
            "two" => "B",
            "three" => "C"
        },
        "test" => "Hello"
    }}
}
{
    "operation" => "composite",
    "address" => [],
    "steps" => [
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "one"
        },
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "two"
        },
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "three"
        }
    ]
}
Model After: {
    "deployment" => undefined,
    "subsystem" => {"test-subsystem" => {
        "properties" => {
            "one" => "A",
            "two" => "B"
        },
        "test" => "Hello"
    }}
}
{code}
The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demonstrate the problem. These tests should be expanded to cover more of the map operations when used in a composite.

  was:
When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
{code}
Model Before: {
    "deployment" => undefined,
    "subsystem" => {"test-subsystem" => {
        "properties" => {
            "one" => "A",
            "two" => "B",
            "three" => "C"
        },
        "test" => "Hello"
    }}
}
{
    "operation" => "composite",
    "address" => [],
    "steps" => [
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "one"
        },
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "two"
        },
        {
            "operation" => "map-remove",
            "address" => [("subsystem" => "test-subsystem")],
            "name" => "properties",
            "key" => "three"
        }
    ]
}
Model After: {
    "deployment" => undefined,
    "subsystem" => {"test-subsystem" => {
        "properties" => {
            "one" => "A",
            "two" => "B"
        },
        "test" => "Hello"
    }}
}
{code}
The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demostrate the problem.



> list-xxx and map-xxx do not work in a composite
> -----------------------------------------------
>
>                 Key: WFCORE-967
>                 URL: https://issues.jboss.org/browse/WFCORE-967
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>            Reporter: Kabir Khan
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
> {code}
> Model Before: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B",
>             "three" => "C"
>         },
>         "test" => "Hello"
>     }}
> }
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "one"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "two"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "three"
>         }
>     ]
> }
> Model After: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B"
>         },
>         "test" => "Hello"
>     }}
> }
> {code}
> The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demonstrate the problem. These tests should be expanded to cover more of the map operations when used in a composite.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 16:15:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Sep 2015 16:15:01 -0400 (EDT)
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.12550.1441743301041@Atlassian.JIRA>


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

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

Dan McPherson <dmcphers at redhat.com> changed the Status of [bug 1220300|https://bugzilla.redhat.com/show_bug.cgi?id=1220300] from VERIFIED to CLOSED

> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 17:25:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 17:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-968) WriteAttributeHandler needs
 to add steps to the top of the queue
In-Reply-To: <JIRA.12584309.1441747490000@Atlassian.JIRA>
References: <JIRA.12584309.1441747490000@Atlassian.JIRA>
	<JIRA.12584309.1441747490005@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584309.1441747490000.12793.1441747500067@Atlassian.JIRA>

Brian Stansberry created WFCORE-968:
---------------------------------------

             Summary: WriteAttributeHandler needs to add steps to the top of the queue
                 Key: WFCORE-968
                 URL: https://issues.jboss.org/browse/WFCORE-968
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta6
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Critical
             Fix For: 2.0.0.CR1


WriteAttributeHandler is adding a bunch of steps that make up elements of its Stage.MODEL execution, but it isn't adding them with the 'addFirst' param set to true. This means the effective order of model changes within a composite op is not going to match the logical order of the steps in the op, and step 2 might not execute with the expected starting state.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 17:36:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 8 Sep 2015 17:36:00 -0400 (EDT)
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.1441748101879@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584311.1441748101000.12803.1441748160105@Atlassian.JIRA>

Stuart Douglas created WFLY-5298:
------------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 17:43:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 8 Sep 2015 17:43:00 -0400 (EDT)
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.12814.1441748580103@Atlassian.JIRA>


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

Harald Pehl updated WFLY-5294:
------------------------------
    Summary: Upgrade HAL to 2.8.8.Final  (was: Upgrade HAL to 2.8.8)


> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 18:37:00 2015
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Tue, 8 Sep 2015 18:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml
 resource in the released JGroups jar
In-Reply-To: <JIRA.12584316.1441751776000@Atlassian.JIRA>
References: <JIRA.12584316.1441751776000@Atlassian.JIRA>
	<JIRA.12584316.1441751776718@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584316.1441751776000.12863.1441751820158@Atlassian.JIRA>

Sanne Grinovero created JGRP-1962:
-------------------------------------

             Summary: Do not include the log4j2.xml resource in the released JGroups jar
                 Key: JGRP-1962
                 URL: https://issues.jboss.org/browse/JGRP-1962
             Project: JGroups
          Issue Type: Task
    Affects Versions: 3.6.4
            Reporter: Sanne Grinovero
            Assignee: Bela Ban


The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-967) list-xxx and map-xxx do not
 work in a composite
In-Reply-To: <JIRA.12584305.1441741810000@Atlassian.JIRA>
References: <JIRA.12584305.1441741810000@Atlassian.JIRA>
	<JIRA.12584305.1441741810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584305.1441741810000.12952.1441754880641@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-967:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1045


> list-xxx and map-xxx do not work in a composite
> -----------------------------------------------
>
>                 Key: WFCORE-967
>                 URL: https://issues.jboss.org/browse/WFCORE-967
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>            Reporter: Kabir Khan
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
> {code}
> Model Before: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B",
>             "three" => "C"
>         },
>         "test" => "Hello"
>     }}
> }
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "one"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "two"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "three"
>         }
>     ]
> }
> Model After: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B"
>         },
>         "test" => "Hello"
>     }}
> }
> {code}
> The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demonstrate the problem. These tests should be expanded to cover more of the map operations when used in a composite.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-967) list-xxx and map-xxx do not
 work in a composite
In-Reply-To: <JIRA.12584305.1441741810000@Atlassian.JIRA>
References: <JIRA.12584305.1441741810000@Atlassian.JIRA>
	<JIRA.12584305.1441741810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584305.1441741810000.12957.1441754880770@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-967:
---------------------------------------

      Assignee: Brian Stansberry  (was: Tomaz Cerar)
    Resolution: Done


> list-xxx and map-xxx do not work in a composite
> -----------------------------------------------
>
>                 Key: WFCORE-967
>                 URL: https://issues.jboss.org/browse/WFCORE-967
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> When running e.g. a series of map-add operations in a composite, only the last step takes effect. e.g.:
> {code}
> Model Before: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B",
>             "three" => "C"
>         },
>         "test" => "Hello"
>     }}
> }
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "one"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "two"
>         },
>         {
>             "operation" => "map-remove",
>             "address" => [("subsystem" => "test-subsystem")],
>             "name" => "properties",
>             "key" => "three"
>         }
>     ]
> }
> Model After: {
>     "deployment" => undefined,
>     "subsystem" => {"test-subsystem" => {
>         "properties" => {
>             "one" => "A",
>             "two" => "B"
>         },
>         "test" => "Hello"
>     }}
> }
> {code}
> The same happens with map-put, map-remove, list-add and list-remove when used in a composite. I have added some more tests to https://github.com/kabir/wildfly-core/blob/map-operation-composite/controller/src/test/java/org/jboss/as/controller/operation/global/CollectionOperationsTestCase.java to demonstrate the problem. These tests should be expanded to cover more of the map operations when used in a composite.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-968) WriteAttributeHandler needs
 to add steps to the top of the queue
In-Reply-To: <JIRA.12584309.1441747490000@Atlassian.JIRA>
References: <JIRA.12584309.1441747490000@Atlassian.JIRA>
	<JIRA.12584309.1441747490000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584309.1441747490000.12959.1441754880799@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-968:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1045


> WriteAttributeHandler needs to add steps to the top of the queue
> ----------------------------------------------------------------
>
>                 Key: WFCORE-968
>                 URL: https://issues.jboss.org/browse/WFCORE-968
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta6
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>
> WriteAttributeHandler is adding a bunch of steps that make up elements of its Stage.MODEL execution, but it isn't adding them with the 'addFirst' param set to true. This means the effective order of model changes within a composite op is not going to match the logical order of the steps in the op, and step 2 might not execute with the expected starting state.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 19:36:00 2015
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Tue, 8 Sep 2015 19:36:00 -0400 (EDT)
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.13004.1441755360105@Atlassian.JIRA>


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

Cheng Fang commented on WFLY-5264:
----------------------------------

JBeret 1.2.0.Final is out:
https://issues.jboss.org/projects/JBERET/versions/12327860

> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 21:47:00 2015
From: issues at jboss.org (Sande Gilda (JIRA))
Date: Tue, 8 Sep 2015 21:47:00 -0400 (EDT)
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.1441763198022@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584323.1441763198000.13087.1441763220312@Atlassian.JIRA>

Sande Gilda created WFLY-5299:
---------------------------------

             Summary: 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


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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep  8 23:08:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Sep 2015 23:08:00 -0400 (EDT)
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.13135.1441768080171@Atlassian.JIRA>


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

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

Chao Wang <chaowan at redhat.com> changed the Status of [bug 1259952|https://bugzilla.redhat.com/show_bug.cgi?id=1259952] from ASSIGNED to CLOSED

> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 00:02:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 9 Sep 2015 00:02:00 -0400 (EDT)
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.1441771262693@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584327.1441771262000.13140.1441771320187@Atlassian.JIRA>

Stuart Douglas created WFLY-5300:
------------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 00:40:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 00:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml
 resource in the released JGroups jar
In-Reply-To: <JIRA.12584316.1441751776000@Atlassian.JIRA>
References: <JIRA.12584316.1441751776000@Atlassian.JIRA>
	<JIRA.12584316.1441751776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584316.1441751776000.13146.1441773600298@Atlassian.JIRA>


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

Bela Ban updated JGRP-1962:
---------------------------
    Fix Version/s: 3.6.5


> Do not include the log4j2.xml resource in the released JGroups jar
> ------------------------------------------------------------------
>
>                 Key: JGRP-1962
>                 URL: https://issues.jboss.org/browse/JGRP-1962
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.6.4
>            Reporter: Sanne Grinovero
>            Assignee: Bela Ban
>             Fix For: 3.6.5
>
>
> The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 01:58:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 01:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1963) TCP_NIO2 starts dropping
	messages
In-Reply-To: <JIRA.12584330.1441778256000@Atlassian.JIRA>
References: <JIRA.12584330.1441778256000@Atlassian.JIRA>
	<JIRA.12584330.1441778256754@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584330.1441778256000.13173.1441778280271@Atlassian.JIRA>

Bela Ban created JGRP-1963:
------------------------------

             Summary: TCP_NIO2 starts dropping messages
                 Key: JGRP-1963
                 URL: https://issues.jboss.org/browse/JGRP-1963
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.6.5
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Critical
             Fix For: 3.6.6


At some point, {{TCP_NIO2}} starts dropping messages, at either the send or receive direction (still need to find out). This shows itself when e.g. a JOIN fails: the joiner sends a lot of {{JOIN-REQ}} messages and gets {{JOIN-RSP}} msgs from the coord, but doesn't receive them.
If {{GMS.max_join_attempts="0"}}, then this goes on forever, or until the joiner doesn't discover any nodes anymore.
{{probe.sh jmx=UNICAST3.printConnections}} shows that messages are sent but no acks are received.
Clearing the connection table in {{TCP_NIO2}} fixes the problem: {{probe.sh op=TCP_NIO2.clearConnections}}. 
This shows that the issue is indeed in {{TCP_NIO2}}. Also, {{TCP}} and {{UDP}} work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 02:14:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 02:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1963) TCP_NIO2 starts dropping
	messages
In-Reply-To: <JIRA.12584330.1441778256000@Atlassian.JIRA>
References: <JIRA.12584330.1441778256000@Atlassian.JIRA>
	<JIRA.12584330.1441778256000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584330.1441778256000.13180.1441779240084@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1963:
--------------------------------

When we get into this state, one connection (the joiner, to the coord) has interestOps of {{OP_CONNECT}} for a long time. This should not be the case, because - after connection - {{OP_READ}} should be set and {{OP_CONNECT}} cleared.

> TCP_NIO2 starts dropping messages
> ---------------------------------
>
>                 Key: JGRP-1963
>                 URL: https://issues.jboss.org/browse/JGRP-1963
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> At some point, {{TCP_NIO2}} starts dropping messages, at either the send or receive direction (still need to find out). This shows itself when e.g. a JOIN fails: the joiner sends a lot of {{JOIN-REQ}} messages and gets {{JOIN-RSP}} msgs from the coord, but doesn't receive them.
> If {{GMS.max_join_attempts="0"}}, then this goes on forever, or until the joiner doesn't discover any nodes anymore.
> {{probe.sh jmx=UNICAST3.printConnections}} shows that messages are sent but no acks are received.
> Clearing the connection table in {{TCP_NIO2}} fixes the problem: {{probe.sh op=TCP_NIO2.clearConnections}}. 
> This shows that the issue is indeed in {{TCP_NIO2}}. Also, {{TCP}} and {{UDP}} work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 02:37:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Wed, 9 Sep 2015 02:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.13214.1441780620177@Atlassian.JIRA>


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

Ladislav Thon commented on JBMETA-387:
--------------------------------------

This is partially fixed. Looking at https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_10_0.xsd, the obsolete clustering configuration elements are no longer present, but the {{<cache-name/>}} description still uses the AS6 syntax. Can we get that fixed?

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 02:39:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Wed, 9 Sep 2015 02:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.13219.1441780740148@Atlassian.JIRA>


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

Ladislav Thon edited comment on JBMETA-387 at 9/9/15 2:38 AM:
--------------------------------------------------------------

I don't know how this works, but can we retroactively fix the description of {{<cache-name>}} in {{jboss-web_7_0.xsd}} and {{jboss-web_7_1.xsd}} too?

EDIT: and in {{jboss-web_8_0.xsd}}


was (Author: lthon):
I don't know how this works, but can we retroactively fix the description of {{<cache-name>}} in {{jboss-web_7_0.xsd}} and {{jboss-web_7_1.xsd}} too?

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 02:58:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Sep 2015 02:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-969) Improve subsystem test to be
 able to test operation transformers with attachments in one go
In-Reply-To: <JIRA.12584332.1441781832000@Atlassian.JIRA>
References: <JIRA.12584332.1441781832000@Atlassian.JIRA>
	<JIRA.12584332.1441781832127@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584332.1441781832000.13238.1441781880702@Atlassian.JIRA>

Kabir Khan created WFCORE-969:
---------------------------------

             Summary: Improve subsystem test to be able to test operation transformers with attachments in one go
                 Key: WFCORE-969
                 URL: https://issues.jboss.org/browse/WFCORE-969
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR1


This is important for being able to test composite operations. The current 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 03:10:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Wed, 9 Sep 2015 03:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.13271.1441782600361@Atlassian.JIRA>


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

Ladislav Thon commented on JBMETA-387:
--------------------------------------

I tried to create a pull request: https://github.com/jboss/metadata/pull/89 Not sure if I met all the rules of the metadata project... :-)

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 03:22:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Sep 2015 03:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-969) Improve subsystem test to be
 able to test operation transformers with attachments in one go
In-Reply-To: <JIRA.12584332.1441781832000@Atlassian.JIRA>
References: <JIRA.12584332.1441781832000@Atlassian.JIRA>
	<JIRA.12584332.1441781832000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584332.1441781832000.13307.1441783320236@Atlassian.JIRA>


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

Kabir Khan updated WFCORE-969:
------------------------------
    Description: This is important for being able to test composite operations. The current way of grabbing the attachment after every operation invocation yourself and passing it in again wasn't really working.  (was: This is important for being able to test composite operations. The current )


> Improve subsystem test to be able to test operation transformers with attachments in one go
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-969
>                 URL: https://issues.jboss.org/browse/WFCORE-969
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>
> This is important for being able to test composite operations. The current way of grabbing the attachment after every operation invocation yourself and passing it in again wasn't really working.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 03:22:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Sep 2015 03:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-969) Improve subsystem test to be
 able to test operation transformers with attachments in one go
In-Reply-To: <JIRA.12584332.1441781832000@Atlassian.JIRA>
References: <JIRA.12584332.1441781832000@Atlassian.JIRA>
	<JIRA.12584332.1441781832000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584332.1441781832000.13311.1441783320366@Atlassian.JIRA>


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

Kabir Khan reassigned WFCORE-969:
---------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


> Improve subsystem test to be able to test operation transformers with attachments in one go
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-969
>                 URL: https://issues.jboss.org/browse/WFCORE-969
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 2.0.0.CR1
>
>
> This is important for being able to test composite operations. The current way of grabbing the attachment after every operation invocation yourself and passing it in again wasn't really working.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 03:57:00 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 9 Sep 2015 03:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-907) Add team page on
 kiegroup.org that links to the team pages of drools,
 jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses
 requests)
In-Reply-To: <JIRA.12584206.1441702460000@Atlassian.JIRA>
References: <JIRA.12584206.1441702460000@Atlassian.JIRA>
	<JIRA.12584206.1441702460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584206.1441702460000.14526.1441785420311@Atlassian.JIRA>


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

Michael Biarnes Kiefer commented on DROOLS-907:
-----------------------------------------------

As kie-group website is not prepared for rake I have done a "short term solution" adding links to this page.
Please look at the image:!kie-group.png|thumbnail!
What do you think?

> Add team page on kiegroup.org that links to the team pages of drools, jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses requests)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-907
>                 URL: https://issues.jboss.org/browse/DROOLS-907
>             Project: Drools
>          Issue Type: Enhancement
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>         Attachments: kie-group.png
>
>
> Add a team page for the kiegroup website
>   http://www.kiegroup.org/
> that links to these 3 pages:
>   http://www.drools.org/community/team.html
>   http://www.optaplanner.org/community/team.html
>   http://www.jbpm.org/community/team.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 03:57:00 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 9 Sep 2015 03:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-907) Add team page on
 kiegroup.org that links to the team pages of drools,
 jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses
 requests)
In-Reply-To: <JIRA.12584206.1441702460000@Atlassian.JIRA>
References: <JIRA.12584206.1441702460000@Atlassian.JIRA>
	<JIRA.12584206.1441702460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584206.1441702460000.14523.1441785420205@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-907:
------------------------------------------
    Attachment: kie-group.png


> Add team page on kiegroup.org that links to the team pages of drools, jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses requests)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-907
>                 URL: https://issues.jboss.org/browse/DROOLS-907
>             Project: Drools
>          Issue Type: Enhancement
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>         Attachments: kie-group.png
>
>
> Add a team page for the kiegroup website
>   http://www.kiegroup.org/
> that links to these 3 pages:
>   http://www.drools.org/community/team.html
>   http://www.optaplanner.org/community/team.html
>   http://www.jbpm.org/community/team.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 04:08:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 9 Sep 2015 04:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-907) Add team page on
 kiegroup.org that links to the team pages of drools,
 jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses
 requests)
In-Reply-To: <JIRA.12584206.1441702460000@Atlassian.JIRA>
References: <JIRA.12584206.1441702460000@Atlassian.JIRA>
	<JIRA.12584206.1441702460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584206.1441702460000.14578.1441786080145@Atlassian.JIRA>


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

Geoffrey De Smet commented on DROOLS-907:
-----------------------------------------

Thanks, this is a good stopgap for the license request team page url problem.

> Add team page on kiegroup.org that links to the team pages of drools, jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses requests)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-907
>                 URL: https://issues.jboss.org/browse/DROOLS-907
>             Project: Drools
>          Issue Type: Enhancement
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>         Attachments: kie-group.png
>
>
> Add a team page for the kiegroup website
>   http://www.kiegroup.org/
> that links to these 3 pages:
>   http://www.drools.org/community/team.html
>   http://www.optaplanner.org/community/team.html
>   http://www.jbpm.org/community/team.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 04:10:00 2015
From: issues at jboss.org (Karel Suta (JIRA))
Date: Wed, 9 Sep 2015 04:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-847) WebLogic unable to deploy
 Execution server
In-Reply-To: <JIRA.12577878.1436798088000@Atlassian.JIRA>
References: <JIRA.12577878.1436798088000@Atlassian.JIRA>
	<JIRA.12577878.1436798088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577878.1436798088000.14612.1441786200486@Atlassian.JIRA>


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

Karel Suta commented on DROOLS-847:
-----------------------------------

After latest changes everything seems to work, kie server successfully deployed on WebLogic, all tests passed.

> WebLogic unable to deploy Execution server
> ------------------------------------------
>
>                 Key: DROOLS-847
>                 URL: https://issues.jboss.org/browse/DROOLS-847
>             Project: Drools
>          Issue Type: Sub-task
>          Components: kie server
>    Affects Versions: 6.3.0.Beta2
>         Environment: WebLogic
>            Reporter: Karel Suta
>            Assignee: Edson Tirelli
>             Fix For: 6.3.0.Final
>
>
> Unified Execution server WAR doesn't contain dependency on Hibernate needed by jBPM part. This is ok for Wildfly which has its own Hibernate module included, but WebLogic and possibly Websphere doesn't contain Hibernate causing ClassNotFoundException when deploying exec server.
> One of possible solution would be to create separate war for WebLogic and Websphere, as is done for Business Central, containing container specific resources.
> Tried on ee6 WAR, same as was used in previous release.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 04:11:00 2015
From: issues at jboss.org (Karel Suta (JIRA))
Date: Wed, 9 Sep 2015 04:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-847) WebLogic unable to deploy
 Execution server
In-Reply-To: <JIRA.12577878.1436798088000@Atlassian.JIRA>
References: <JIRA.12577878.1436798088000@Atlassian.JIRA>
	<JIRA.12577878.1436798088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577878.1436798088000.14615.1441786260297@Atlassian.JIRA>


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

Karel Suta resolved DROOLS-847.
-------------------------------
     QE Status: VERIFIED  (was: ASSIGNED)
      Assignee: Karel Suta  (was: Edson Tirelli)
    Resolution: Done


> WebLogic unable to deploy Execution server
> ------------------------------------------
>
>                 Key: DROOLS-847
>                 URL: https://issues.jboss.org/browse/DROOLS-847
>             Project: Drools
>          Issue Type: Sub-task
>          Components: kie server
>    Affects Versions: 6.3.0.Beta2
>         Environment: WebLogic
>            Reporter: Karel Suta
>            Assignee: Karel Suta
>             Fix For: 6.3.0.Final
>
>
> Unified Execution server WAR doesn't contain dependency on Hibernate needed by jBPM part. This is ok for Wildfly which has its own Hibernate module included, but WebLogic and possibly Websphere doesn't contain Hibernate causing ClassNotFoundException when deploying exec server.
> One of possible solution would be to create separate war for WebLogic and Websphere, as is done for Business Central, containing container specific resources.
> Tried on ee6 WAR, same as was used in previous release.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 04:13:00 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 9 Sep 2015 04:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-907) Add team page on
 kiegroup.org that links to the team pages of drools,
 jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses
 requests)
In-Reply-To: <JIRA.12584206.1441702460000@Atlassian.JIRA>
References: <JIRA.12584206.1441702460000@Atlassian.JIRA>
	<JIRA.12584206.1441702460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584206.1441702460000.14628.1441786380204@Atlassian.JIRA>


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

Michael Biarnes Kiefer resolved DROOLS-907.
-------------------------------------------
    Resolution: Done


> Add team page on kiegroup.org that links to the team pages of drools, jbpm and optaplanner (for IntelliJ/JProfiler/Onxygen open source licenses requests)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-907
>                 URL: https://issues.jboss.org/browse/DROOLS-907
>             Project: Drools
>          Issue Type: Enhancement
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>         Attachments: kie-group.png
>
>
> Add a team page for the kiegroup website
>   http://www.kiegroup.org/
> that links to these 3 pages:
>   http://www.drools.org/community/team.html
>   http://www.optaplanner.org/community/team.html
>   http://www.jbpm.org/community/team.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 04:27:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 04:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5301) IllegalStateException:
 Address <node_name> is no longer in the cluster
In-Reply-To: <JIRA.12584352.1441787202000@Atlassian.JIRA>
References: <JIRA.12584352.1441787202000@Atlassian.JIRA>
	<JIRA.12584352.1441787202271@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584352.1441787202000.14685.1441787220196@Atlassian.JIRA>

Michal Vinkler created WFLY-5301:
------------------------------------

             Summary: IllegalStateException: Address <node_name> is no longer in the cluster
                 Key: WFLY-5301
                 URL: https://issues.jboss.org/browse/WFLY-5301
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
            Reporter: Michal Vinkler
            Assignee: Paul Ferraro
            Priority: Minor


EAP 7.0.0.DR9
scenario: failover-ejb-ejbremote-jvmkill-repl-sync

Perf19 logged IllegalStateException several times when restarting after failover:

{code}
[JBossINF] [0m[0m13:01:20,040 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 11660ms - Started 760 of 1018 services (446 services are lazy, passive or on-demand)
2015/08/28 13:01:20:040 EDT [DEBUG][Thread-67] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossStartup, server started!
[JBossINF] [0m[0m13:01:23,055 INFO  [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 2.1.2.Final
[JBossINF] [0m[0m13:02:25,343 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,perf19) ISPN000094: Received new cluster view for channel web: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m13:02:25,346 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[31m13:02:30,273 ERROR [org.jboss.as.ejb3.remote] (EJB default - 2) WFLYEJB0151: Exception while generating session id for component RemoteStatefulSBImpl with invocation id: 7468 on channel Channel ID 435dee65 (inbound) of Remoting connection 19f8ad2f to /10.16.90.52:45746: javax.ejb.EJBException: java.lang.IllegalStateException: Address perf19 is no longer in the cluster
[JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:263)
[JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:145)
[JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: java.lang.IllegalStateException: Address perf19 is no longer in the cluster
[JBossINF] 	at org.infinispan.affinity.impl.KeyAffinityServiceImpl.getKeyForAddress(KeyAffinityServiceImpl.java:120)
[JBossINF] 	at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager$2.createIdentifier(InfinispanBeanManager.java:121)
[JBossINF] 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:85)
[JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
[JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:258)
[JBossINF] 	... 7 more
[JBossINF] 
{code}

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-jvmkill-repl-sync/5/console-perf19/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 04:27:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 04:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5301) IllegalStateException:
 Address <node_name> is no longer in the cluster
In-Reply-To: <JIRA.12584352.1441787202000@Atlassian.JIRA>
References: <JIRA.12584352.1441787202000@Atlassian.JIRA>
	<JIRA.12584352.1441787202000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584352.1441787202000.14690.1441787220358@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5301:
---------------------------------
    Affects Version/s: 10.0.0.Beta1


> IllegalStateException: Address <node_name> is no longer in the cluster
> ----------------------------------------------------------------------
>
>                 Key: WFLY-5301
>                 URL: https://issues.jboss.org/browse/WFLY-5301
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>            Priority: Minor
>
> EAP 7.0.0.DR9
> scenario: failover-ejb-ejbremote-jvmkill-repl-sync
> Perf19 logged IllegalStateException several times when restarting after failover:
> {code}
> [JBossINF] [0m[0m13:01:20,040 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 11660ms - Started 760 of 1018 services (446 services are lazy, passive or on-demand)
> 2015/08/28 13:01:20:040 EDT [DEBUG][Thread-67] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossStartup, server started!
> [JBossINF] [0m[0m13:01:23,055 INFO  [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 2.1.2.Final
> [JBossINF] [0m[0m13:02:25,343 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,perf19) ISPN000094: Received new cluster view for channel web: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] [0m[0m13:02:25,346 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] [0m[31m13:02:30,273 ERROR [org.jboss.as.ejb3.remote] (EJB default - 2) WFLYEJB0151: Exception while generating session id for component RemoteStatefulSBImpl with invocation id: 7468 on channel Channel ID 435dee65 (inbound) of Remoting connection 19f8ad2f to /10.16.90.52:45746: javax.ejb.EJBException: java.lang.IllegalStateException: Address perf19 is no longer in the cluster
> [JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:263)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:145)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: java.lang.IllegalStateException: Address perf19 is no longer in the cluster
> [JBossINF] 	at org.infinispan.affinity.impl.KeyAffinityServiceImpl.getKeyForAddress(KeyAffinityServiceImpl.java:120)
> [JBossINF] 	at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager$2.createIdentifier(InfinispanBeanManager.java:121)
> [JBossINF] 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:85)
> [JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> [JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:258)
> [JBossINF] 	... 7 more
> [JBossINF] 
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-jvmkill-repl-sync/5/console-perf19/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 04:32:00 2015
From: issues at jboss.org (=?UTF-8?Q?Jan_Ka=C5=A1=C3=ADk_=28JIRA=29?=)
Date: Wed, 9 Sep 2015 04:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5302) No items present in EE
 subsystem -> services tables
In-Reply-To: <JIRA.12584353.1441787499000@Atlassian.JIRA>
References: <JIRA.12584353.1441787499000@Atlassian.JIRA>
	<JIRA.12584353.1441787499809@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584353.1441787499000.14709.1441787520197@Atlassian.JIRA>

Jan Ka??k created WFLY-5302:
-------------------------------

             Summary: No items present in EE subsystem -> services tables
                 Key: WFLY-5302
                 URL: https://issues.jboss.org/browse/WFLY-5302
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
    Affects Versions: 10.0.0.Beta2
         Environment: Fedora 22
- Firefox 31.2.0esr
- Firefox 40.0.3

Ubuntu 14.04
- Firefox 40.0.3
            Reporter: Jan Ka??k
            Assignee: Heiko Braun
         Attachments: wildfly-ee_after.png, wildfly-ee_before.png

When trying to configure EE subsystem using web console, no context services, executors, scheduled executor or thread factories appear in corresponding tables.
I could reproduce this bug only with Firefox browser with new (clean) profile.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep  9 04:41:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 9 Sep 2015 04:41:00 -0400 (EDT)
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.14732.1441788060202@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-3171:
--------------------------------------

PS: related fix in infinispan https://github.com/infinispan/infinispan/pull/3695

> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 05:18:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Sep 2015 05:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Support for SPNEGO
 authentication for deployed web applications
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.14832.1441790281281@Atlassian.JIRA>


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

Darran Lofthouse commented on WFLY-2553:
----------------------------------------

Thinking on this further the simplest options seems to be a new authentication mechanism, possibly even in the JBoss Negotiation project that can still work with the existing login modules and security domain configurations - this way configuration on the server is unchanged and users do not need to migrate to the security realms that are also deprecated.

Subsequently once integrated all users can switch to the WildFly Elytron approach.

> Support for SPNEGO authentication for deployed web applications
> ---------------------------------------------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 05:19:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 05:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1963) TCP_NIO2 starts dropping
	messages
In-Reply-To: <JIRA.12584330.1441778256000@Atlassian.JIRA>
References: <JIRA.12584330.1441778256000@Atlassian.JIRA>
	<JIRA.12584330.1441778256000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584330.1441778256000.14836.1441790340107@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1963:
--------------------------------

The problem is on the receiver side: the NioConnection in question had only {{OP_CONNECT}} set *although the channel was connected*, but not {{OP_READ}}, which caused {{netstat -na}} to show a pileup of bytes to be read to be shown.
Investigating why {{OP_CONNECT}} was not cleared and {{OP_READ}} set.

> TCP_NIO2 starts dropping messages
> ---------------------------------
>
>                 Key: JGRP-1963
>                 URL: https://issues.jboss.org/browse/JGRP-1963
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> At some point, {{TCP_NIO2}} starts dropping messages, at either the send or receive direction (still need to find out). This shows itself when e.g. a JOIN fails: the joiner sends a lot of {{JOIN-REQ}} messages and gets {{JOIN-RSP}} msgs from the coord, but doesn't receive them.
> If {{GMS.max_join_attempts="0"}}, then this goes on forever, or until the joiner doesn't discover any nodes anymore.
> {{probe.sh jmx=UNICAST3.printConnections}} shows that messages are sent but no acks are received.
> Clearing the connection table in {{TCP_NIO2}} fixes the problem: {{probe.sh op=TCP_NIO2.clearConnections}}. 
> This shows that the issue is indeed in {{TCP_NIO2}}. Also, {{TCP}} and {{UDP}} work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 05:43:00 2015
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 9 Sep 2015 05:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5303) ironojacamar 1.3.0
In-Reply-To: <JIRA.12584370.1441791747000@Atlassian.JIRA>
References: <JIRA.12584370.1441791747000@Atlassian.JIRA>
	<JIRA.12584370.1441791747950@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584370.1441791747000.14873.1441791780394@Atlassian.JIRA>

Stefano Maestri created WFLY-5303:
-------------------------------------

             Summary: ironojacamar 1.3.0
                 Key: WFLY-5303
                 URL: https://issues.jboss.org/browse/WFLY-5303
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: JCA
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 06:40:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 06:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1963) TCP_NIO2 starts dropping
	messages
In-Reply-To: <JIRA.12584330.1441778256000@Atlassian.JIRA>
References: <JIRA.12584330.1441778256000@Atlassian.JIRA>
	<JIRA.12584330.1441778256000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584330.1441778256000.14972.1441795200102@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1963:
--------------------------------

Looks like the reason is that the selector went into a loop where {{select()}} always returned 0. Is this the infamous selector loop bug ? Should have been fixed a long time ago, at least in Java 8 (which I'm using)...

> TCP_NIO2 starts dropping messages
> ---------------------------------
>
>                 Key: JGRP-1963
>                 URL: https://issues.jboss.org/browse/JGRP-1963
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> At some point, {{TCP_NIO2}} starts dropping messages, at either the send or receive direction (still need to find out). This shows itself when e.g. a JOIN fails: the joiner sends a lot of {{JOIN-REQ}} messages and gets {{JOIN-RSP}} msgs from the coord, but doesn't receive them.
> If {{GMS.max_join_attempts="0"}}, then this goes on forever, or until the joiner doesn't discover any nodes anymore.
> {{probe.sh jmx=UNICAST3.printConnections}} shows that messages are sent but no acks are received.
> Clearing the connection table in {{TCP_NIO2}} fixes the problem: {{probe.sh op=TCP_NIO2.clearConnections}}. 
> This shows that the issue is indeed in {{TCP_NIO2}}. Also, {{TCP}} and {{UDP}} work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 06:54:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 06:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5304) NullPointerException during
 server graceful shutdown after EJBCLient invocation arrived
In-Reply-To: <JIRA.12584375.1441795993000@Atlassian.JIRA>
References: <JIRA.12584375.1441795993000@Atlassian.JIRA>
	<JIRA.12584375.1441795993296@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584375.1441795993000.15007.1441796040224@Atlassian.JIRA>

Michal Vinkler created WFLY-5304:
------------------------------------

             Summary: NullPointerException during server graceful shutdown after EJBCLient invocation arrived
                 Key: WFLY-5304
                 URL: https://issues.jboss.org/browse/WFLY-5304
             Project: WildFly
          Issue Type: Bug
          Components: Clustering, EJB, Remoting
            Reporter: Michal Vinkler
            Assignee: Paul Ferraro
            Priority: Minor


EAP 7.0.0.DR9
Scenario: ejb-ejbremote-shutdown-repl-async

Perf21 logged NPE just before it gracefully shut down:

{code}
[JBossINF] [0m[31m09:02:25,058 ERROR [org.jboss.as.ejb3.remote] (default task-24) WFLYEJB0148: Exception on channel Channel ID 423b1c54 (inbound) of Remoting connection 41f997cb to /10.16.90.52:54492 from message org.jboss.remoting3.remote.InboundMessage$3 at 45c60b2c: java.lang.NullPointerException
[JBossINF] 	at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:152)
[JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.EJBIdentifierBasedMessageHandler.findEJB(EJBIdentifierBasedMessageHandler.java:46)
[JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:124)
[JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
[JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
[JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:157)
[JBossINF] 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
[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] 
[JBossINF] [0m[0m09:02:25,104 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
[JBossINF] [0m[0m09:02:25,108 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 3 entries in 3 milliseconds
[JBossINF] [0m[0m09:02:25,131 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
[JBossINF] [0m[0m09:02:25,132 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 81) WFLYCLINF0003: Stopped repl cache from ejb container
[JBossINF] [0m[0m09:02:25,148 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow AJP listener ajp suspending
[JBossINF] [0m[0m09:02:25,151 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to perf21/10.16.90.60:8080
[JBossINF] [0m[0m09:02:25,156 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 1024ms
[JBossINF] [0m[0m09:02:25,156 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 1055ms
[JBossINF] [0m[0m09:02:25,156 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 1041ms
[JBossINF] [0m[0m09:02:25,167 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
[JBossINF] [0m[0m09:02:25,169 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to perf21/10.16.90.60:8009
[JBossINF] [0m[0m09:02:25,169 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 1054ms
[JBossINF] [0m[0m09:02:25,170 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
[JBossINF] [0m[0m09:02:25,171 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
[JBossINF] [0m[0m09:02:25,275 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 1125ms
{code}

Graceful shutdown timeout was set to 300 seconds. 
It does not seem to generate any kind of error on the client.

The similar issue was already mentioned by Richard Achmatowicz here:
https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13076866&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13076866

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-shutdown-repl-async/6/console-perf21/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 06:54:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 06:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5304) NullPointerException during
 server graceful shutdown after EJBCLient invocation arrived
In-Reply-To: <JIRA.12584375.1441795993000@Atlassian.JIRA>
References: <JIRA.12584375.1441795993000@Atlassian.JIRA>
	<JIRA.12584375.1441795993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584375.1441795993000.15012.1441796040351@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5304:
---------------------------------
    Affects Version/s: 10.0.0.Beta1


> NullPointerException during server graceful shutdown after EJBCLient invocation arrived
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-5304
>                 URL: https://issues.jboss.org/browse/WFLY-5304
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB, Remoting
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>            Priority: Minor
>
> EAP 7.0.0.DR9
> Scenario: ejb-ejbremote-shutdown-repl-async
> Perf21 logged NPE just before it gracefully shut down:
> {code}
> [JBossINF] [0m[31m09:02:25,058 ERROR [org.jboss.as.ejb3.remote] (default task-24) WFLYEJB0148: Exception on channel Channel ID 423b1c54 (inbound) of Remoting connection 41f997cb to /10.16.90.52:54492 from message org.jboss.remoting3.remote.InboundMessage$3 at 45c60b2c: java.lang.NullPointerException
> [JBossINF] 	at org.jboss.as.ejb3.deployment.DeploymentRepository.getStartedModules(DeploymentRepository.java:152)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.EJBIdentifierBasedMessageHandler.findEJB(EJBIdentifierBasedMessageHandler.java:46)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:124)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:157)
> [JBossINF] 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:463)
> [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] 
> [JBossINF] [0m[0m09:02:25,104 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m09:02:25,108 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 3 entries in 3 milliseconds
> [JBossINF] [0m[0m09:02:25,131 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> [JBossINF] [0m[0m09:02:25,132 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 81) WFLYCLINF0003: Stopped repl cache from ejb container
> [JBossINF] [0m[0m09:02:25,148 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow AJP listener ajp suspending
> [JBossINF] [0m[0m09:02:25,151 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to perf21/10.16.90.60:8080
> [JBossINF] [0m[0m09:02:25,156 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 1024ms
> [JBossINF] [0m[0m09:02:25,156 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 1055ms
> [JBossINF] [0m[0m09:02:25,156 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 1041ms
> [JBossINF] [0m[0m09:02:25,167 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[0m09:02:25,169 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to perf21/10.16.90.60:8009
> [JBossINF] [0m[0m09:02:25,169 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 1054ms
> [JBossINF] [0m[0m09:02:25,170 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] [0m[0m09:02:25,171 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> [JBossINF] [0m[0m09:02:25,275 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 1125ms
> {code}
> Graceful shutdown timeout was set to 300 seconds. 
> It does not seem to generate any kind of error on the client.
> The similar issue was already mentioned by Richard Achmatowicz here:
> https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13076866&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13076866
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-shutdown-repl-async/6/console-perf21/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:02:00 2015
From: issues at jboss.org (Laurent Pereira (JIRA))
Date: Wed, 9 Sep 2015 07:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5305) Security subsystem
 configuration element security-properties not working
In-Reply-To: <JIRA.12584379.1441796499000@Atlassian.JIRA>
References: <JIRA.12584379.1441796499000@Atlassian.JIRA>
	<JIRA.12584379.1441796499227@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584379.1441796499000.15029.1441796520161@Atlassian.JIRA>

Laurent Pereira created WFLY-5305:
-------------------------------------

             Summary: Security subsystem configuration element security-properties not working
                 Key: WFLY-5305
                 URL: https://issues.jboss.org/browse/WFLY-5305
             Project: WildFly
          Issue Type: Bug
          Components: Security
    Affects Versions: 9.0.1.Final
            Reporter: Laurent Pereira
            Assignee: Darran Lofthouse


>From wildfly security system configuration documentation, there is 
{quote}
security-properties

This element is used to specify additional properties as required by the security subsystem, properties are specified in the following format:
<security-properties>
  <property name="..." value="..."/>
</security-properties>

The property element can be repeated as required for as many properties need to be defined.

Each property specified is set on the java.security.Security class.
{quote}

However when I add this this configuration to standalone.xml
{code:xml}
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-properties>
  <property name="myproperty" value="myvalue"/>
</security-properties>
</subsystem>
{code}

Then the property is not set in java.security.Security.

I digged in wildfly sources and I found this in SecuritySubsystemParser.java : 
{code:java}
                case SECURITY_PROPERTIES:
                    reader.discardRemainder();
                    break;
{code}

It seems that this feature is not implemented.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:11:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Sep 2015 07:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5305) Security subsystem
 configuration element security-properties not working
In-Reply-To: <JIRA.12584379.1441796499000@Atlassian.JIRA>
References: <JIRA.12584379.1441796499000@Atlassian.JIRA>
	<JIRA.12584379.1441796499000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584379.1441796499000.15055.1441797060194@Atlassian.JIRA>


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

Darran Lofthouse reassigned WFLY-5305:
--------------------------------------

    Assignee:     (was: Darran Lofthouse)


> Security subsystem configuration element security-properties not working
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5305
>                 URL: https://issues.jboss.org/browse/WFLY-5305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 9.0.1.Final
>            Reporter: Laurent Pereira
>
> From wildfly security system configuration documentation, there is 
> {quote}
> security-properties
> This element is used to specify additional properties as required by the security subsystem, properties are specified in the following format:
> <security-properties>
>   <property name="..." value="..."/>
> </security-properties>
> The property element can be repeated as required for as many properties need to be defined.
> Each property specified is set on the java.security.Security class.
> {quote}
> However when I add this this configuration to standalone.xml
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-properties>
>   <property name="myproperty" value="myvalue"/>
> </security-properties>
> </subsystem>
> {code}
> Then the property is not set in java.security.Security.
> I digged in wildfly sources and I found this in SecuritySubsystemParser.java : 
> {code:java}
>                 case SECURITY_PROPERTIES:
>                     reader.discardRemainder();
>                     break;
> {code}
> It seems that this feature is not implemented.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:30:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Wed, 9 Sep 2015 07:30:00 -0400 (EDT)
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.1441798148787@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584386.1441798148000.15115.1441798200298@Atlassian.JIRA>

Ladislav Thon created WFLY-5306:
-----------------------------------

             Summary: 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
            Reporter: Ladislav Thon
            Assignee: Brian Stansberry
            Priority: Critical


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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:30:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 9 Sep 2015 07:30:00 -0400 (EDT)
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.15119.1441798200452@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-5287:
---------------------------------
    Fix Version/s: 10.0.0.CR1


> 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: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:30:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Wed, 9 Sep 2015 07:30:00 -0400 (EDT)
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.15123.1441798200529@Atlassian.JIRA>


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

Ladislav Thon reassigned WFLY-5306:
-----------------------------------

    Assignee: Stuart Douglas  (was: Brian Stansberry)


> 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
>            Reporter: Ladislav Thon
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:30:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 9 Sep 2015 07:30:00 -0400 (EDT)
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.15126.1441798200595@Atlassian.JIRA>


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

Radoslav Husar edited comment on WFLY-5287 at 9/9/15 7:29 AM:
--------------------------------------------------------------

Commit that introduces this change in infinispan upstream: https://github.com/infinispan/infinispan/commit/8b15769fd4d608f345d95b0e1b8840188c270e33


was (Author: rhusar):
https://github.com/infinispan/infinispan/commit/8b15769fd4d608f345d95b0e1b8840188c270e33

> 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: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:31:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Wed, 9 Sep 2015 07:31:00 -0400 (EDT)
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.15131.1441798260376@Atlassian.JIRA>


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

Ladislav Thon commented on WFLY-5306:
-------------------------------------

I'm tentatively assigning to Stuart, as he already handled WFLY-5092.

> 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
>            Reporter: Ladislav Thon
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:33:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Wed, 9 Sep 2015 07:33:00 -0400 (EDT)
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.15140.1441798380094@Atlassian.JIRA>


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

Ladislav Thon updated WFLY-5306:
--------------------------------
    Affects Version/s: 10.0.0.Beta2


> 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
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 07:48:00 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 9 Sep 2015 07:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5303) ironojacamar 1.3.0
In-Reply-To: <JIRA.12584370.1441791747000@Atlassian.JIRA>
References: <JIRA.12584370.1441791747000@Atlassian.JIRA>
	<JIRA.12584370.1441791747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584370.1441791747000.15165.1441799280201@Atlassian.JIRA>


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

Jesper Pedersen closed WFLY-5303.
---------------------------------
    Resolution: Duplicate Issue


WFY-5297

> ironojacamar 1.3.0
> ------------------
>
>                 Key: WFLY-5303
>                 URL: https://issues.jboss.org/browse/WFLY-5303
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:12:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5307) CacheException: Initial state
 transfer timed out for cache
In-Reply-To: <JIRA.12584392.1441800694000@Atlassian.JIRA>
References: <JIRA.12584392.1441800694000@Atlassian.JIRA>
	<JIRA.12584392.1441800694166@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584392.1441800694000.15246.1441800720365@Atlassian.JIRA>

Michal Vinkler created WFLY-5307:
------------------------------------

             Summary: CacheException: Initial state transfer timed out for cache
                 Key: WFLY-5307
                 URL: https://issues.jboss.org/browse/WFLY-5307
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
            Reporter: Michal Vinkler
            Assignee: Paul Ferraro


EAP 7.0.0.DR9
Scenario: failover-ejb-ejbremote-undeploy-dist-async

During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):

{code}
[JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
[JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
[JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
[JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
[JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
[JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
[JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
[JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
[JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[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] 
[JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
[JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
[JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
[JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
[JBossINF] 	... 4 more
[JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
[JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
[JBossINF] 	... 19 more
[JBossINF] 
[JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
{code} 

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/

This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:12:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5307) CacheException: Initial state
 transfer timed out for cache
In-Reply-To: <JIRA.12584392.1441800694000@Atlassian.JIRA>
References: <JIRA.12584392.1441800694000@Atlassian.JIRA>
	<JIRA.12584392.1441800694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584392.1441800694000.15251.1441800720519@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5307:
---------------------------------
    Affects Version/s: 10.0.0.Beta1


> CacheException: Initial state transfer timed out for cache
> ----------------------------------------------------------
>
>                 Key: WFLY-5307
>                 URL: https://issues.jboss.org/browse/WFLY-5307
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):
> {code}
> [JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> [JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
> [JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
> [JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [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] 
> [JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> [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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> [JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> [JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> [JBossINF] 	... 4 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> [JBossINF] 	... 19 more
> [JBossINF] 
> [JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
> {code} 
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/
> This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:21:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 08:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5307) CacheException: Initial state
 transfer timed out for cache
In-Reply-To: <JIRA.12584392.1441800694000@Atlassian.JIRA>
References: <JIRA.12584392.1441800694000@Atlassian.JIRA>
	<JIRA.12584392.1441800694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584392.1441800694000.15291.1441801260595@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5307:
---------------------------------
    Description: 
EAP 7.0.0.DR9
Scenario: failover-ejb-ejbremote-undeploy-dist-async

During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):

{code}
[JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
[JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
[JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
[JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
[JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
[JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
[JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
[JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
[JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[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] 
[JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
[JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
[JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
[JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
[JBossINF] 	... 4 more
[JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
[JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
[JBossINF] 	... 19 more
[JBossINF] 
[JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
{code} 

Which ends up with WFLYSRV0021: *Deploy of deployment "clusterbench-ee7.ear" was rolled back*.
Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/

This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]

  was:
EAP 7.0.0.DR9
Scenario: failover-ejb-ejbremote-undeploy-dist-async

During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):

{code}
[JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
[JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
[JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
[JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
[JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
[JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
[JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
[JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
[JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[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] 
[JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
[JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
[JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
[JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
[JBossINF] 	... 4 more
[JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
[JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
[JBossINF] 	... 19 more
[JBossINF] 
[JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
{code} 

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/

This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



> CacheException: Initial state transfer timed out for cache
> ----------------------------------------------------------
>
>                 Key: WFLY-5307
>                 URL: https://issues.jboss.org/browse/WFLY-5307
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):
> {code}
> [JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> [JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
> [JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
> [JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [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] 
> [JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> [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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> [JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> [JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> [JBossINF] 	... 4 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> [JBossINF] 	... 19 more
> [JBossINF] 
> [JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
> {code} 
> Which ends up with WFLYSRV0021: *Deploy of deployment "clusterbench-ee7.ear" was rolled back*.
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/
> This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:39:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 08:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5307) CacheException: Initial state
 transfer timed out for cache
In-Reply-To: <JIRA.12584392.1441800694000@Atlassian.JIRA>
References: <JIRA.12584392.1441800694000@Atlassian.JIRA>
	<JIRA.12584392.1441800694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584392.1441800694000.15420.1441802340345@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5307:
---------------------------------
    Description: 
EAP 7.0.0.DR9
Scenario: failover-ejb-ejbremote-undeploy-dist-async

During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):

{code}
[JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
[JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
[JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
[JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
[JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
[JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
[JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
[JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
[JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[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] 
[JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
[JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
[JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
[JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
[JBossINF] 	... 4 more
[JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
[JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
[JBossINF] 	... 19 more
[JBossINF] 
[JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
{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 perf20, can be related: JBEAP-1043

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/

This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]

  was:
EAP 7.0.0.DR9
Scenario: failover-ejb-ejbremote-undeploy-dist-async

During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):

{code}
[JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
[JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
[JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
[JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
[JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
[JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
[JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
[JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
[JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[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] 
[JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
[JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
[JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
[JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
[JBossINF] 	... 4 more
[JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
[JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
[JBossINF] 	... 19 more
[JBossINF] 
[JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
{code} 

Which ends up with WFLYSRV0021: *Deploy of deployment "clusterbench-ee7.ear" was rolled back*.
Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/

This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



> CacheException: Initial state transfer timed out for cache
> ----------------------------------------------------------
>
>                 Key: WFLY-5307
>                 URL: https://issues.jboss.org/browse/WFLY-5307
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):
> {code}
> [JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> [JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
> [JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
> [JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [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] 
> [JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> [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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> [JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> [JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> [JBossINF] 	... 4 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> [JBossINF] 	... 19 more
> [JBossINF] 
> [JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
> {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 perf20, can be related: JBEAP-1043
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/
> This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:39:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 08:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5307) CacheException: Initial state
 transfer timed out for cache
In-Reply-To: <JIRA.12584392.1441800694000@Atlassian.JIRA>
References: <JIRA.12584392.1441800694000@Atlassian.JIRA>
	<JIRA.12584392.1441800694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584392.1441800694000.15438.1441802340835@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5307:
---------------------------------
    Description: 
EAP 7.0.0.DR9
Scenario: failover-ejb-ejbremote-undeploy-dist-async

During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):

{code}
[JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
[JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
[JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
[JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
[JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
[JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
[JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
[JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
[JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[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] 
[JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
[JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
[JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
[JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
[JBossINF] 	... 4 more
[JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
[JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
[JBossINF] 	... 19 more
[JBossINF] 
[JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
{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 perf20, may be related: JBEAP-1043

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/

This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]

  was:
EAP 7.0.0.DR9
Scenario: failover-ejb-ejbremote-undeploy-dist-async

During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):

{code}
[JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
[JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
[JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
[JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
[JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
[JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
[JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
[JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
[JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
[JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
[JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[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] 
[JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
[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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
[JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
[JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
[JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
[JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
[JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
[JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
[JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
[JBossINF] 	... 4 more
[JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
[JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
[JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
[JBossINF] 	... 19 more
[JBossINF] 
[JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
{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 perf20, can be related: JBEAP-1043

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/

This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



> CacheException: Initial state transfer timed out for cache
> ----------------------------------------------------------
>
>                 Key: WFLY-5307
>                 URL: https://issues.jboss.org/browse/WFLY-5307
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):
> {code}
> [JBossINF] [0m[0m15:29:55,511 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:29:55,513 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:29:55,516 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[0m15:29:55,538 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:55,539 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:56,499 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> [JBossINF] [0m[0m15:30:00,507 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 5293c097.
> [JBossINF] [0m[0m15:30:01,323 INFO  [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl at 4dfb0a03.
> [JBossINF] [0m[33m15:30:55,461 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [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] 
> [JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> [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] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> [JBossINF] 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> [JBossINF] 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> [JBossINF] 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> [JBossINF] 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> [JBossINF] 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> [JBossINF] 	... 4 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> [JBossINF] 	... 19 more
> [JBossINF] 
> [JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
> {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 perf20, may be related: JBEAP-1043
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf18/
> This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:41:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 08:41:00 -0400 (EDT)
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.1441802434067@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584398.1441802434000.15454.1441802460229@Atlassian.JIRA>

Michal Vinkler created WFLY-5308:
------------------------------------

             Summary:  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
            Reporter: Michal Vinkler
            Assignee: Paul Ferraro


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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:41:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 08:41:00 -0400 (EDT)
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.15463.1441802460662@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5308:
---------------------------------
    Affects Version/s: 10.0.0.Beta1


>  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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:47:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 9 Sep 2015 08:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5235) CDI interceptors are not
 called when invoking observer method
In-Reply-To: <JIRA.12583196.1440938405000@Atlassian.JIRA>
References: <JIRA.12583196.1440938405000@Atlassian.JIRA>
	<JIRA.12583196.1440938405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583196.1440938405000.15489.1441802820141@Atlassian.JIRA>


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

Scott Marlow commented on WFLY-5235:
------------------------------------

What happens on WildFly 10?  There were a few changes in Hibernate 5.0, in how we join the entity manager to the transaction.  There was also a JPA container bug resolved as well.  I'm not sure if either has anything to do with the reported issue.  Let us know if the problem reproduces with WildFly 10.  If it does reproduce with WildFly 10, could you enable TRACE logging for org.jboss.as.jpa?  See [https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Troubleshooting] for how.

> CDI interceptors are not called when invoking observer method
> -------------------------------------------------------------
>
>                 Key: WFLY-5235
>                 URL: https://issues.jboss.org/browse/WFLY-5235
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 9.0.1.Final
>            Reporter: Dirk Weil
>            Assignee: Martin Kouba
>
> The following code runs with an active transaction on WFLY 8.2.0, but failes with an TransactionRequiredException on WFLY 9.0.1:
> @ApplicationScoped
> public class InitCocktailDemoDataService
> {
>   @PersistenceContext
>   private EntityManager entityManager;
>   @Transactional
>   private void createDemoData(@Observes @Initialized(ApplicationScoped.class) Object event)
>   {
>         this.entityManager.merge(someEntity);
>       }
> It seems that interceptors aren't called at all - at least for observers of scope lifecycle events.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 08:50:00 2015
From: issues at jboss.org (Ja kub (JIRA))
Date: Wed, 9 Sep 2015 08:50:00 -0400 (EDT)
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.1441802956098@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584401.1441802956000.15503.1441803000424@Atlassian.JIRA>

Ja kub created WFLY-5309:
----------------------------

             Summary: jsf/richfaces problem on wildfly 
                 Key: WFLY-5309
                 URL: https://issues.jboss.org/browse/WFLY-5309
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 9.0.1.Final
            Reporter: Ja kub
            Assignee: Stuart Douglas
         Attachments: pom.xml, 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 09:08:00 2015
From: issues at jboss.org (Timo Riikonen (JIRA))
Date: Wed, 9 Sep 2015 09:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-908) Class load error with
 slf4j-api on Tomcat8
In-Reply-To: <JIRA.12584404.1441804062000@Atlassian.JIRA>
References: <JIRA.12584404.1441804062000@Atlassian.JIRA>
	<JIRA.12584404.1441804062062@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584404.1441804062000.15580.1441804080146@Atlassian.JIRA>

Timo Riikonen created DROOLS-908:
------------------------------------

             Summary: Class load error with slf4j-api on Tomcat8
                 Key: DROOLS-908
                 URL: https://issues.jboss.org/browse/DROOLS-908
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 6.3.0.CR2
         Environment: apache-tomcat-8.0.26

            Reporter: Timo Riikonen
            Assignee: Edson Tirelli


Installation instructions request that slf4j-api JAR file is copied to Tomcats lib directory. And correctly also as the Tomcat won't start if it is not in there.
But then this API conflicts with the same API in kie-server-6.3.0.CR2-ee7.

I did a quick fix that seemed to solve this:

# Removed kie-server WAR file from tomcat webapps directory, so that it won't undo the next step.
# Deleted the problem file webapps/kie-server-6.3.0.CR2-ee7/WEB-INF/lib/slf4j-api-1.7.2.jar

I considered removing the jar file from Drools project, but that is likely to cause other errors, so I decided to leave this to the experts (= you guys).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 09:15:02 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 9 Sep 2015 09:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5305) Security subsystem
 configuration element security-properties not working
In-Reply-To: <JIRA.12584379.1441796499000@Atlassian.JIRA>
References: <JIRA.12584379.1441796499000@Atlassian.JIRA>
	<JIRA.12584379.1441796499000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584379.1441796499000.15601.1441804502933@Atlassian.JIRA>


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

Tomaz Cerar closed WFLY-5305.
-----------------------------
    Resolution: Rejected


security-properties element was part of xsd 1.0 and removed in all newer versions.
Support for that was removed before 7.1.0 and wasn't supported since.

this is commit that removed it back in 2011 https://github.com/wildfly/wildfly/commit/f8622daa145c66def640af7a45056da8a8b6fcb9

> Security subsystem configuration element security-properties not working
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5305
>                 URL: https://issues.jboss.org/browse/WFLY-5305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 9.0.1.Final
>            Reporter: Laurent Pereira
>
> From wildfly security system configuration documentation, there is 
> {quote}
> security-properties
> This element is used to specify additional properties as required by the security subsystem, properties are specified in the following format:
> <security-properties>
>   <property name="..." value="..."/>
> </security-properties>
> The property element can be repeated as required for as many properties need to be defined.
> Each property specified is set on the java.security.Security class.
> {quote}
> However when I add this this configuration to standalone.xml
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-properties>
>   <property name="myproperty" value="myvalue"/>
> </security-properties>
> </subsystem>
> {code}
> Then the property is not set in java.security.Security.
> I digged in wildfly sources and I found this in SecuritySubsystemParser.java : 
> {code:java}
>                 case SECURITY_PROPERTIES:
>                     reader.discardRemainder();
>                     break;
> {code}
> It seems that this feature is not implemented.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 09:33:00 2015
From: issues at jboss.org (Laurent Pereira (JIRA))
Date: Wed, 9 Sep 2015 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5305) Security subsystem
 configuration element security-properties not working
In-Reply-To: <JIRA.12584379.1441796499000@Atlassian.JIRA>
References: <JIRA.12584379.1441796499000@Atlassian.JIRA>
	<JIRA.12584379.1441796499000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584379.1441796499000.15683.1441805580157@Atlassian.JIRA>


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

Laurent Pereira commented on WFLY-5305:
---------------------------------------

I understand but then this means the documention at https://docs.jboss.org/author/display/WFLY9/Security+subsystem+configuration is not uptodate.
It is quite mislisleading, sorry.

> Security subsystem configuration element security-properties not working
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5305
>                 URL: https://issues.jboss.org/browse/WFLY-5305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 9.0.1.Final
>            Reporter: Laurent Pereira
>
> From wildfly security system configuration documentation, there is 
> {quote}
> security-properties
> This element is used to specify additional properties as required by the security subsystem, properties are specified in the following format:
> <security-properties>
>   <property name="..." value="..."/>
> </security-properties>
> The property element can be repeated as required for as many properties need to be defined.
> Each property specified is set on the java.security.Security class.
> {quote}
> However when I add this this configuration to standalone.xml
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-properties>
>   <property name="myproperty" value="myvalue"/>
> </security-properties>
> </subsystem>
> {code}
> Then the property is not set in java.security.Security.
> I digged in wildfly sources and I found this in SecuritySubsystemParser.java : 
> {code:java}
>                 case SECURITY_PROPERTIES:
>                     reader.discardRemainder();
>                     break;
> {code}
> It seems that this feature is not implemented.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 09:34:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 09:34:00 -0400 (EDT)
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.15691.1441805640146@Atlassian.JIRA>


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

Brian Stansberry commented on WFLY-5306:
----------------------------------------

I believe the technical issue I meant was that removing the extension within the series of execution steps may interfere with the execution of the other steps, since the removal will mean all the resource definitions and handlers associated with the legacy extension will be gone.

This is probably an avoidable issue, avoided via careful arrangement of step execution. Perhaps trivially avoided just by doing things in the intuitively obvious order.

> 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
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 09:37:00 2015
From: issues at jboss.org (Timo Riikonen (JIRA))
Date: Wed, 9 Sep 2015 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-908) Class load error with
 slf4j-api on Tomcat8
In-Reply-To: <JIRA.12584404.1441804062000@Atlassian.JIRA>
References: <JIRA.12584404.1441804062000@Atlassian.JIRA>
	<JIRA.12584404.1441804062000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584404.1441804062000.15713.1441805820149@Atlassian.JIRA>


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

Timo Riikonen updated DROOLS-908:
---------------------------------
    Steps to Reproduce: 
1) Install latest Tomcat8
2) Follow installation instructions within *kie-drools-wb-distribution-wars-6.3.0.CR2-tomcat7* WAR file
3) Try to start the server


  was:
1) Install latest Tomcat8
2) Follow installation instructions within kie-server-6.3.0.CR2-ee7 WAR file
3) Try to start the server




> Class load error with slf4j-api on Tomcat8
> ------------------------------------------
>
>                 Key: DROOLS-908
>                 URL: https://issues.jboss.org/browse/DROOLS-908
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR2
>         Environment: apache-tomcat-8.0.26
>            Reporter: Timo Riikonen
>            Assignee: Edson Tirelli
>
> Installation instructions request that slf4j-api JAR file is copied to Tomcats lib directory. And correctly also as the Tomcat won't start if it is not in there.
> But then this API conflicts with the same API in kie-server-6.3.0.CR2-ee7.
> I did a quick fix that seemed to solve this:
> # Removed kie-server WAR file from tomcat webapps directory, so that it won't undo the next step.
> # Deleted the problem file webapps/kie-server-6.3.0.CR2-ee7/WEB-INF/lib/slf4j-api-1.7.2.jar
> I considered removing the jar file from Drools project, but that is likely to cause other errors, so I decided to leave this to the experts (= you guys).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 09:57:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 9 Sep 2015 09:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.15874.1441807020149@Atlassian.JIRA>


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

Geoffrey De Smet commented on WFLY-5279:
----------------------------------------

>From a user's perspective it's confusing that 8.2.1 bom doesn't match widfly 8.2.1 but 8.2.0 instead - maybe for future similar cases it would be called 8.2.0.1 instead, so there's room for 8.2.1?
We definitely have a potential issue due to this, as we're using wildfly 8.2.1 with wildfly-bom 8.2.1 which is apparently a bad combination.

Any reason why the 9.0.1.Final bom isn't available on Maven Central?


> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
> [2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:06:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Sep 2015 10:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-910) Add an Undertow SPNEGO
 authentication mechanism
In-Reply-To: <JIRA.12584412.1441807528000@Atlassian.JIRA>
References: <JIRA.12584412.1441807528000@Atlassian.JIRA>
	<JIRA.12584412.1441807528117@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584412.1441807528000.15910.1441807560286@Atlassian.JIRA>

Darran Lofthouse created SECURITY-910:
-----------------------------------------

             Summary: Add an Undertow SPNEGO authentication mechanism
                 Key: SECURITY-910
                 URL: https://issues.jboss.org/browse/SECURITY-910
             Project: PicketBox 
          Issue Type: Feature Request
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_3_0_0_CR1


Undertow does contain an SPNEGO authentication mechanism however this is not compatible with the LoginModule approach of JBoss Negotiation so an alternative mechanism is required here.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:11:00 2015
From: issues at jboss.org (Eido Reshef (JIRA))
Date: Wed, 9 Sep 2015 10:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) KIE 6.2 Web: when using
 String functions like "toLowerCase" or "ToUpperCase" as part of rule,
 rule do not compile
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848997@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.15919.1441807860501@Atlassian.JIRA>

Eido Reshef created DROOLS-909:
----------------------------------

             Summary: KIE 6.2 Web: when using String functions like "toLowerCase" or "ToUpperCase" as part of rule, rule do not compile
                 Key: DROOLS-909
                 URL: https://issues.jboss.org/browse/DROOLS-909
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 6.2.0.Final
         Environment: No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04 LTS
Release:        12.04
Codename:       precise

CPU: 

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
stepping        : 2
microcode       : 0x15
cpu MHz         : 3066.775
cache size      : 12288 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
bogomips        : 6133.55
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
stepping        : 2
microcode       : 0x15
cpu MHz         : 3066.775
cache size      : 12288 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
bogomips        : 6133.55
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
stepping        : 2
microcode       : 0x15
cpu MHz         : 3066.775
cache size      : 12288 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
bogomips        : 6133.55
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
stepping        : 2
microcode       : 0x15
cpu MHz         : 3066.775
cache size      : 12288 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
bogomips        : 6133.55
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:



Tomcat : apache-tomcat-8.0.24
KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
Java: java version "1.7.0_79"

            Reporter: Eido Reshef
            Assignee: Edson Tirelli
         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG

When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.

So instead of getting for example;
1.	|	package ido.droolsrules.dqsrulesqa;
2.	|	
3.	|	import java.lang.Number;
4.	|	
5.	|	rule "Test Camera Model"
6.	|	    dialect "mvel"
7.	|	    when
8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
9.	|	    then
10.	|	        cam1.setLens( 5.0 );
11.	|	end

Rule is generated (In source tab) as:

1.	|	package ebay.droolsrules.dqsrulesqa;
2.	|	
3.	|	import java.lang.Number;
4.	|	
5.	|	rule "Test Camera Model"
6.	|	    dialect "mvel"
7.	|	    when
8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
9.	|	    then
10.	|	        cam1.setLens( 5.0 );
11.	|	end


view line 8 to spot difference.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:16:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 9 Sep 2015 10:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) KIE 6.2 Web: when using
 String functions like "toLowerCase" or "ToUpperCase" as part of rule,
 rule do not compile
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.15945.1441808160177@Atlassian.JIRA>


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

Edson Tirelli reassigned DROOLS-909:
------------------------------------

    Assignee: Michael Anstis  (was: Edson Tirelli)


> KIE 6.2 Web: when using String functions like "toLowerCase" or "ToUpperCase" as part of rule, rule do not compile
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-909
>                 URL: https://issues.jboss.org/browse/DROOLS-909
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>         Environment: No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 12.04 LTS
> Release:        12.04
> Codename:       precise
> CPU: 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 2
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> Tomcat : apache-tomcat-8.0.24
> KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
> Java: java version "1.7.0_79"
>            Reporter: Eido Reshef
>            Assignee: Michael Anstis
>         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG
>
>
> When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
> Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.
> So instead of getting for example;
> 1.	|	package ido.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> Rule is generated (In source tab) as:
> 1.	|	package ebay.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> view line 8 to spot difference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:19:00 2015
From: issues at jboss.org (Robert (Bob) Brodt (JIRA))
Date: Wed, 9 Sep 2015 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-910) Kie Navigator Server
 Property dialog does not save user creds
In-Reply-To: <JIRA.12584414.1441808297000@Atlassian.JIRA>
References: <JIRA.12584414.1441808297000@Atlassian.JIRA>
	<JIRA.12584414.1441808297626@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584414.1441808297000.15958.1441808340104@Atlassian.JIRA>

Robert (Bob) Brodt created DROOLS-910:
-----------------------------------------

             Summary: Kie Navigator Server Property dialog does not save user creds
                 Key: DROOLS-910
                 URL: https://issues.jboss.org/browse/DROOLS-910
             Project: Drools
          Issue Type: Bug
          Components: eclipse plugin
    Affects Versions: 6.3.0.CR2
            Reporter: Robert (Bob) Brodt
            Assignee: Robert (Bob) Brodt
             Fix For: 6.3.0.Final


The Server Property dialog from Kie Navigator view does not save the username/password information and always defaults to admin/admin.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:19:00 2015
From: issues at jboss.org (Eido Reshef (JIRA))
Date: Wed, 9 Sep 2015 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) KIE 6.2 Web: when using
 String functions like "toLowerCase" or "ToUpperCase" as part of rule,
 rule do not compile
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.15961.1441808340195@Atlassian.JIRA>


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

Eido Reshef commented on DROOLS-909:
------------------------------------

It seems manstis has solved the issue.

> KIE 6.2 Web: when using String functions like "toLowerCase" or "ToUpperCase" as part of rule, rule do not compile
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-909
>                 URL: https://issues.jboss.org/browse/DROOLS-909
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>         Environment: No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 12.04 LTS
> Release:        12.04
> Codename:       precise
> CPU: 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 2
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> Tomcat : apache-tomcat-8.0.24
> KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
> Java: java version "1.7.0_79"
>            Reporter: Eido Reshef
>            Assignee: Michael Anstis
>         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG
>
>
> When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
> Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.
> So instead of getting for example;
> 1.	|	package ido.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> Rule is generated (In source tab) as:
> 1.	|	package ebay.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> view line 8 to spot difference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:20:00 2015
From: issues at jboss.org (Eido Reshef (JIRA))
Date: Wed, 9 Sep 2015 10:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) KIE 6.2 Web: when using
 String functions like "toLowerCase" or "ToUpperCase" as part of rule,
 rule do not compile
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.15964.1441808400164@Atlassian.JIRA>


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

Eido Reshef commented on DROOLS-909:
------------------------------------

It seems manstis has solved the issue.

> KIE 6.2 Web: when using String functions like "toLowerCase" or "ToUpperCase" as part of rule, rule do not compile
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-909
>                 URL: https://issues.jboss.org/browse/DROOLS-909
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>         Environment: No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 12.04 LTS
> Release:        12.04
> Codename:       precise
> CPU: 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 2
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> Tomcat : apache-tomcat-8.0.24
> KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
> Java: java version "1.7.0_79"
>            Reporter: Eido Reshef
>            Assignee: Michael Anstis
>         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG
>
>
> When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
> Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.
> So instead of getting for example;
> 1.	|	package ido.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> Rule is generated (In source tab) as:
> 1.	|	package ebay.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> view line 8 to spot difference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:21:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 10:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1963) TCP_NIO2 starts dropping
	messages
In-Reply-To: <JIRA.12584330.1441778256000@Atlassian.JIRA>
References: <JIRA.12584330.1441778256000@Atlassian.JIRA>
	<JIRA.12584330.1441778256000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584330.1441778256000.15971.1441808460248@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1963:
--------------------------------

Ok, so here's what happens:
* Apparently an {{OP_CONNECT}} flag on an already connected channel leads to a loop with {{select()}} always returning 0
* So {{OP_CONNECT}} has to be cleared. However...
* While {{OP_CONNECT}} is cleared in the select-loop, {{OP_READ}} is added by reading the old value of interestOps (still {{OP_CONNECT}} !) and anding it with {{OP_READ}} --> {{OP_CONNECT | OP_READ}}
* This is because {{SelectionKey.interestOps(ops)}} is not thread safe.
SOLUTION: write a method to change the selection key which is thread safe and has to be used by all threads

> TCP_NIO2 starts dropping messages
> ---------------------------------
>
>                 Key: JGRP-1963
>                 URL: https://issues.jboss.org/browse/JGRP-1963
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> At some point, {{TCP_NIO2}} starts dropping messages, at either the send or receive direction (still need to find out). This shows itself when e.g. a JOIN fails: the joiner sends a lot of {{JOIN-REQ}} messages and gets {{JOIN-RSP}} msgs from the coord, but doesn't receive them.
> If {{GMS.max_join_attempts="0"}}, then this goes on forever, or until the joiner doesn't discover any nodes anymore.
> {{probe.sh jmx=UNICAST3.printConnections}} shows that messages are sent but no acks are received.
> Clearing the connection table in {{TCP_NIO2}} fixes the problem: {{probe.sh op=TCP_NIO2.clearConnections}}. 
> This shows that the issue is indeed in {{TCP_NIO2}}. Also, {{TCP}} and {{UDP}} work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:29:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 10:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5310) WARN HttpContextLifecycle
 guard leak detected. The Servlet container is not fully compliant during
 application deployment
In-Reply-To: <JIRA.12584416.1441808910000@Atlassian.JIRA>
References: <JIRA.12584416.1441808910000@Atlassian.JIRA>
	<JIRA.12584416.1441808910726@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584416.1441808910000.16029.1441808940245@Atlassian.JIRA>

Michal Vinkler created WFLY-5310:
------------------------------------

             Summary: WARN HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant during application deployment
                 Key: WFLY-5310
                 URL: https://issues.jboss.org/browse/WFLY-5310
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
            Reporter: Michal Vinkler
            Assignee: Stuart Douglas
            Priority: Minor


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-async (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with asynchronously replicated cache)

During application re-deployment (after previous undeployment) on any of the nodes, this WARN message is being logged approx. 60 times - stacktrace:
{code}
[JBossINF] [0m[0m19:07:15,617 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
2015/08/28 19:07:15:621 EDT [DEBUG][RMI TCP Connection(16)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Got result: {"outcome" : "success"}
[JBossINF] [0m[0m19:07:20,563 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0033: Deployment clusterbench-ee7.ear was previously undeployed by this scanner but has been redeployed by another management tool. Marker file /tmp/hudson/jboss-eap-7.0/standalone/deployments/clusterbench-ee7.ear.undeployed is being removed to record this fact.
[JBossINF] [0m[33m19:08:01,353 WARN  [org.jboss.weld.Servlet] (default task-2) WELD-000714: HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant. The value was 1
{code}

Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-undeploy-repl-async/6/console-perf18/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:30:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 9 Sep 2015 10:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5310) WARN HttpContextLifecycle
 guard leak detected. The Servlet container is not fully compliant during
 application deployment
In-Reply-To: <JIRA.12584416.1441808910000@Atlassian.JIRA>
References: <JIRA.12584416.1441808910000@Atlassian.JIRA>
	<JIRA.12584416.1441808910000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584416.1441808910000.16034.1441809000295@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5310:
---------------------------------
    Affects Version/s: 10.0.0.Beta1


> WARN HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant during application deployment
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5310
>                 URL: https://issues.jboss.org/browse/WFLY-5310
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> 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-async (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with asynchronously replicated cache)
> During application re-deployment (after previous undeployment) on any of the nodes, this WARN message is being logged approx. 60 times - stacktrace:
> {code}
> [JBossINF] [0m[0m19:07:15,617 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 2015/08/28 19:07:15:621 EDT [DEBUG][RMI TCP Connection(16)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Got result: {"outcome" : "success"}
> [JBossINF] [0m[0m19:07:20,563 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0033: Deployment clusterbench-ee7.ear was previously undeployed by this scanner but has been redeployed by another management tool. Marker file /tmp/hudson/jboss-eap-7.0/standalone/deployments/clusterbench-ee7.ear.undeployed is being removed to record this fact.
> [JBossINF] [0m[33m19:08:01,353 WARN  [org.jboss.weld.Servlet] (default task-2) WELD-000714: HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant. The value was 1
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-undeploy-repl-async/6/console-perf18/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:36:00 2015
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 9 Sep 2015 10:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) DROOLS-909: KIE Workbench:
 ExpressionBuilder does not include all MethodInformation's in selector
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.16078.1441809360351@Atlassian.JIRA>


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

Michael Anstis updated DROOLS-909:
----------------------------------
    Summary: DROOLS-909: KIE Workbench: ExpressionBuilder does not include all MethodInformation's in selector  (was: KIE 6.2 Web: when using String functions like "toLowerCase" or "ToUpperCase" as part of rule, rule do not compile)


> DROOLS-909: KIE Workbench: ExpressionBuilder does not include all MethodInformation's in selector
> -------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-909
>                 URL: https://issues.jboss.org/browse/DROOLS-909
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>         Environment: No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 12.04 LTS
> Release:        12.04
> Codename:       precise
> CPU: 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 2
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> Tomcat : apache-tomcat-8.0.24
> KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
> Java: java version "1.7.0_79"
>            Reporter: Eido Reshef
>            Assignee: Michael Anstis
>         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG
>
>
> When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
> Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.
> So instead of getting for example;
> 1.	|	package ido.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> Rule is generated (In source tab) as:
> 1.	|	package ebay.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> view line 8 to spot difference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:40:00 2015
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 9 Sep 2015 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) DROOLS-909: KIE Workbench:
 ExpressionBuilder does not include all MethodInformation's in selector
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.16086.1441809600243@Atlassian.JIRA>


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

Michael Anstis commented on DROOLS-909:
---------------------------------------

See https://github.com/droolsjbpm/drools-wb/pull/63

> DROOLS-909: KIE Workbench: ExpressionBuilder does not include all MethodInformation's in selector
> -------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-909
>                 URL: https://issues.jboss.org/browse/DROOLS-909
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>         Environment: No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 12.04 LTS
> Release:        12.04
> Codename:       precise
> CPU: 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 2
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> Tomcat : apache-tomcat-8.0.24
> KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
> Java: java version "1.7.0_79"
>            Reporter: Eido Reshef
>            Assignee: Michael Anstis
>         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG
>
>
> When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
> Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.
> So instead of getting for example;
> 1.	|	package ido.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> Rule is generated (In source tab) as:
> 1.	|	package ebay.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> view line 8 to spot difference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:48:00 2015
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 9 Sep 2015 10:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) DROOLS-909: KIE Workbench:
 ExpressionBuilder does not include all MethodInformation's in selector
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.16117.1441810080515@Atlassian.JIRA>


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

Michael Anstis commented on DROOLS-909:
---------------------------------------

*drools-wb*
(master) http://github.com/droolsjbpm/drools-wb/commit/3a43c9ebe

(6.3.x) http://github.com/droolsjbpm/drools-wb/commit/e3eefa429

> DROOLS-909: KIE Workbench: ExpressionBuilder does not include all MethodInformation's in selector
> -------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-909
>                 URL: https://issues.jboss.org/browse/DROOLS-909
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>         Environment: No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 12.04 LTS
> Release:        12.04
> Codename:       precise
> CPU: 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 2
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> Tomcat : apache-tomcat-8.0.24
> KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
> Java: java version "1.7.0_79"
>            Reporter: Eido Reshef
>            Assignee: Michael Anstis
>             Fix For: 6.3.0.Final
>
>         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG
>
>
> When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
> Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.
> So instead of getting for example;
> 1.	|	package ido.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> Rule is generated (In source tab) as:
> 1.	|	package ebay.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> view line 8 to spot difference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 10:48:00 2015
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 9 Sep 2015 10:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-909) DROOLS-909: KIE Workbench:
 ExpressionBuilder does not include all MethodInformation's in selector
In-Reply-To: <JIRA.12584413.1441807848000@Atlassian.JIRA>
References: <JIRA.12584413.1441807848000@Atlassian.JIRA>
	<JIRA.12584413.1441807848000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584413.1441807848000.16131.1441810080921@Atlassian.JIRA>


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

Michael Anstis resolved DROOLS-909.
-----------------------------------
    Fix Version/s: 6.3.0.Final
       Resolution: Done


> DROOLS-909: KIE Workbench: ExpressionBuilder does not include all MethodInformation's in selector
> -------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-909
>                 URL: https://issues.jboss.org/browse/DROOLS-909
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>         Environment: No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 12.04 LTS
> Release:        12.04
> Codename:       precise
> CPU: 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 2
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
> stepping        : 2
> microcode       : 0x15
> cpu MHz         : 3066.775
> cache size      : 12288 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dts
> bogomips        : 6133.55
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> Tomcat : apache-tomcat-8.0.24
> KIE: kie-drools-wb-distribution-wars-6.2.0.Final-tomcat7.war
> Java: java version "1.7.0_79"
>            Reporter: Eido Reshef
>            Assignee: Michael Anstis
>             Fix For: 6.3.0.Final
>
>         Attachments: CameraObj.JPG, CameraRuleGuided.JPG, CameraRuleGuidedSource.JPG, CameraRuleGuidedSourceError.JPG
>
>
> When trying to use "Expression editor" in the guided rule screen of the web app, combining with restrictions on String fields which use functions like "toLowerCase" , "toUpperCase" - 
> Expression editor leaves a blanc field to fill and if left blanc - KIE automatically fill it with "" - and rule doesn't get compiled.
> So instead of getting for example;
> 1.	|	package ido.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase() == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> Rule is generated (In source tab) as:
> 1.	|	package ebay.droolsrules.dqsrulesqa;
> 2.	|	
> 3.	|	import java.lang.Number;
> 4.	|	
> 5.	|	rule "Test Camera Model"
> 6.	|	    dialect "mvel"
> 7.	|	    when
> 8.	|	        cam1 : Camera( brand.toLowerCase("") == "sony" )
> 9.	|	    then
> 10.	|	        cam1.setLens( 5.0 );
> 11.	|	end
> view line 8 to spot difference.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:05:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Sep 2015 11:05:00 -0400 (EDT)
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.16226.1441811100177@Atlassian.JIRA>


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

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

Ryan Emerson <remerson at redhat.com> changed the Status of [bug 1252583|https://bugzilla.redhat.com/show_bug.cgi?id=1252583] from ASSIGNED to POST

> 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: Jason Greene
>         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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:17:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Sep 2015 11:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5274) EJB IOR contains wrong port
 (non-SSL port) information when SSL is required
In-Reply-To: <JIRA.12583908.1441311342000@Atlassian.JIRA>
References: <JIRA.12583908.1441311342000@Atlassian.JIRA>
	<JIRA.12583908.1441311342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583908.1441311342000.16311.1441811820180@Atlassian.JIRA>


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

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

Bartek Spyrko-Smietanko <bspyrkos at redhat.com> changed the Status of [bug 1259902|https://bugzilla.redhat.com/show_bug.cgi?id=1259902] from NEW to ASSIGNED

> EJB IOR contains wrong port (non-SSL port) information when SSL is required
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5274
>                 URL: https://issues.jboss.org/browse/WFLY-5274
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Derek Horton
>            Assignee: Jason Greene
>
> Description of problem:
> - Configure JBoss to only allow IIOP connections over SSL
> - It is possible to do this, but the configuration is confusing (possibly a bug)
> Details of the setup/issue:
> - When enabling SSL for jacorb, it normally listens on both the non-ssl port and the ssl port
> - Setting server-requires="ServerAuth" causes the server to stop listening on non-ssl port
> - However, the IOR tells client to connect to non-ssl port ...even though its not listening on it
>         String lookup = "corbaname:iiop:" + host + ":" + port +"#" + ejbLookupPath;
>         // lookup the IIOP EJB
>         Object iiopObj = ctx.lookup(lookup);
>         // the call to the EJB will fail due to the port being wrong non-ssl vs ssl
> - The workaround is to use the following ior-setting to correct the port settings in the IOR
>   /subsystem=jacorb/ior-settings=default/setting=transport-config:add(confidentiality=required)
> - Shouldn't setting "server-requires=ServerAuth" change the port info in the IOR?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:17:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 11:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1963) TCP_NIO2 starts dropping
	messages
In-Reply-To: <JIRA.12584330.1441778256000@Atlassian.JIRA>
References: <JIRA.12584330.1441778256000@Atlassian.JIRA>
	<JIRA.12584330.1441778256000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584330.1441778256000.16315.1441811820325@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1963.
----------------------------
    Resolution: Done


> TCP_NIO2 starts dropping messages
> ---------------------------------
>
>                 Key: JGRP-1963
>                 URL: https://issues.jboss.org/browse/JGRP-1963
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.6.6
>
>
> At some point, {{TCP_NIO2}} starts dropping messages, at either the send or receive direction (still need to find out). This shows itself when e.g. a JOIN fails: the joiner sends a lot of {{JOIN-REQ}} messages and gets {{JOIN-RSP}} msgs from the coord, but doesn't receive them.
> If {{GMS.max_join_attempts="0"}}, then this goes on forever, or until the joiner doesn't discover any nodes anymore.
> {{probe.sh jmx=UNICAST3.printConnections}} shows that messages are sent but no acks are received.
> Clearing the connection table in {{TCP_NIO2}} fixes the problem: {{probe.sh op=TCP_NIO2.clearConnections}}. 
> This shows that the issue is indeed in {{TCP_NIO2}}. Also, {{TCP}} and {{UDP}} work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:28:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 11:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml
 resource in the released JGroups jar
In-Reply-To: <JIRA.12584316.1441751776000@Atlassian.JIRA>
References: <JIRA.12584316.1441751776000@Atlassian.JIRA>
	<JIRA.12584316.1441751776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584316.1441751776000.16387.1441812480271@Atlassian.JIRA>


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

Bela Ban updated JGRP-1962:
---------------------------
    Fix Version/s: 3.6.6
                       (was: 3.6.5)


> Do not include the log4j2.xml resource in the released JGroups jar
> ------------------------------------------------------------------
>
>                 Key: JGRP-1962
>                 URL: https://issues.jboss.org/browse/JGRP-1962
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.6.4
>            Reporter: Sanne Grinovero
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:31:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml
 resource in the released JGroups jar
In-Reply-To: <JIRA.12584316.1441751776000@Atlassian.JIRA>
References: <JIRA.12584316.1441751776000@Atlassian.JIRA>
	<JIRA.12584316.1441751776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584316.1441751776000.16408.1441812660312@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1962.
----------------------------
    Resolution: Done


> Do not include the log4j2.xml resource in the released JGroups jar
> ------------------------------------------------------------------
>
>                 Key: JGRP-1962
>                 URL: https://issues.jboss.org/browse/JGRP-1962
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.6.4
>            Reporter: Sanne Grinovero
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:35:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 9 Sep 2015 11:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5311) Require the two default
 thread-pool and job repository attributes for the batch subsystem
In-Reply-To: <JIRA.12584433.1441812853000@Atlassian.JIRA>
References: <JIRA.12584433.1441812853000@Atlassian.JIRA>
	<JIRA.12584433.1441812853127@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584433.1441812853000.16431.1441812900282@Atlassian.JIRA>

James Perkins created WFLY-5311:
-----------------------------------

             Summary: Require the two default thread-pool and job repository attributes for the batch subsystem
                 Key: WFLY-5311
                 URL: https://issues.jboss.org/browse/WFLY-5311
             Project: WildFly
          Issue Type: Task
          Components: Batch
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Blocker
             Fix For: 10.0.0.Final


Resources, such as the batch subsystem, that provide capabilities must provide ensure their capabilities are provided. Currently the {{default-thread-pool}} and {{default-job-repository}} are not required attributes. If the attributes are not defined then the {{org.wildfly.batch.default.thread.pool}} and {{org.wildfy.batch.default.job.repository}} capabilities are not fulfilled. Making the two attributes required will solve this.

One thing to consider is making the two attributes required does require that both a {{thread-pool}} and either a {{in-memory-job-repository}} or {{jdbc-job-repository}} is defined. It's possible to keep the {{default-job-repository}} optional and just use a default {{InMemoryJobRepository}} if it is undefined. A {{thread-pool}} *must* be defined though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:38:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 9 Sep 2015 11:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml
 resource in the released JGroups jar
In-Reply-To: <JIRA.12584316.1441751776000@Atlassian.JIRA>
References: <JIRA.12584316.1441751776000@Atlassian.JIRA>
	<JIRA.12584316.1441751776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584316.1441751776000.16451.1441813080707@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1962:
--------------------------------

Actually, I need this file to run my unit tests. Why can't you simply use {{-Dlog4j.configuration=/your/home/log4j2.xml}} ?

> Do not include the log4j2.xml resource in the released JGroups jar
> ------------------------------------------------------------------
>
>                 Key: JGRP-1962
>                 URL: https://issues.jboss.org/browse/JGRP-1962
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.6.4
>            Reporter: Sanne Grinovero
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:54:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 9 Sep 2015 11:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5312) component upgrade to
 Hibernate ORM 5.0.1.Final
In-Reply-To: <JIRA.12584438.1441813999000@Atlassian.JIRA>
References: <JIRA.12584438.1441813999000@Atlassian.JIRA>
	<JIRA.12584438.1441813999406@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584438.1441813999000.16543.1441814040195@Atlassian.JIRA>

Scott Marlow created WFLY-5312:
----------------------------------

             Summary: component upgrade to Hibernate ORM 5.0.1.Final
                 Key: WFLY-5312
                 URL: https://issues.jboss.org/browse/WFLY-5312
             Project: WildFly
          Issue Type: Task
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 10.0.0.CR1


Change JPA2LCTestCase to sleep before the EntityManager is created, so the Hibernate session timestamp is different than what the ClassFileTransformerTestCase timestamp was using.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 11:56:00 2015
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 9 Sep 2015 11:56:00 -0400 (EDT)
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.1441814154467@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584439.1441814154000.16561.1441814160573@Atlassian.JIRA>

Sanne Grinovero created WFLY-5313:
-------------------------------------

             Summary: 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 12:06:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 9 Sep 2015 12:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5312) component upgrade to
 Hibernate ORM 5.0.1.Final
In-Reply-To: <JIRA.12584438.1441813999000@Atlassian.JIRA>
References: <JIRA.12584438.1441813999000@Atlassian.JIRA>
	<JIRA.12584438.1441813999000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584438.1441813999000.16626.1441814760795@Atlassian.JIRA>


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

Scott Marlow updated WFLY-5312:
-------------------------------
    Description: Change JPA2LCTestCase to sleep before the EntityManager is created, so the Hibernate session timestamp is different than what the ClassFileTransformerTestCase timestamp.    (was: Change JPA2LCTestCase to sleep before the EntityManager is created, so the Hibernate session timestamp is different than what the ClassFileTransformerTestCase timestamp was using.  )


> component upgrade to Hibernate ORM 5.0.1.Final
> ----------------------------------------------
>
>                 Key: WFLY-5312
>                 URL: https://issues.jboss.org/browse/WFLY-5312
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>
> Change JPA2LCTestCase to sleep before the EntityManager is created, so the Hibernate session timestamp is different than what the ClassFileTransformerTestCase timestamp.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 12:23:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 9 Sep 2015 12:23:00 -0400 (EDT)
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.1441815770890@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584449.1441815770000.16737.1441815780462@Atlassian.JIRA>

Paul Ferraro created WFLY-5314:
----------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 12:40:00 2015
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 9 Sep 2015 12:40:00 -0400 (EDT)
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.1441816790826@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584454.1441816790000.16830.1441816800576@Atlassian.JIRA>

Sanne Grinovero created WFLY-5315:
-------------------------------------

             Summary: 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 13:02:00 2015
From: issues at jboss.org (Amitkumar Raodeo (JIRA))
Date: Wed, 9 Sep 2015 13:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3330) Support
	enabled-cipher-suites="ALL"
In-Reply-To: <JIRA.12540344.1399643221000@Atlassian.JIRA>
References: <JIRA.12540344.1399643221000@Atlassian.JIRA>
	<JIRA.12540344.1399643221000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540344.1399643221000.16971.1441818120299@Atlassian.JIRA>


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

Amitkumar Raodeo commented on WFLY-3330:
----------------------------------------

This is yet not fixed in wildfly 9.0.1 Final.

> Support enabled-cipher-suites="ALL" 
> ------------------------------------
>
>                 Key: WFLY-3330
>                 URL: https://issues.jboss.org/browse/WFLY-3330
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.CR1
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> If I want to enable all ciphers format except MD5 I would have to specify a long list of all supported ciphers.
> Using the "ALL" keyword with a list of excluded elements this becomes easy to configure.
> The expected fopattern would be ALL:!ELT1:!ELT2
> Thus ALL:!MD5 would enable all supported ciphers except MD5.
> This is based on OpenSSL syntax for ciphers https://www.openssl.org/docs/apps/ciphers.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 13:57:00 2015
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 9 Sep 2015 13:57:00 -0400 (EDT)
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.17202.1441821420362@Atlassian.JIRA>


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

Sanne Grinovero updated WFLY-5036:
----------------------------------
    Fix Version/s: 10.0.0.CR1


> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 14:58:00 2015
From: issues at jboss.org (Fernando Nasser (JIRA))
Date: Wed, 9 Sep 2015 14:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5316) Duplicate auth directories in
	Wildfly 10
In-Reply-To: <JIRA.12584467.1441825072000@Atlassian.JIRA>
References: <JIRA.12584467.1441825072000@Atlassian.JIRA>
	<JIRA.12584467.1441825072893@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584467.1441825072000.17618.1441825080084@Atlassian.JIRA>

Fernando Nasser created WFLY-5316:
-------------------------------------

             Summary: Duplicate auth directories in Wildfly 10
                 Key: WFLY-5316
                 URL: https://issues.jboss.org/browse/WFLY-5316
             Project: WildFly
          Issue Type: Bug
          Components: Build System, Security
            Reporter: Fernando Nasser
            Assignee: Paul Gier


The Wildfly 10 build creates two "auth" directories, one under each config:

WILDFLY_HOME/domain/tmp: auth
WILDFLY_HOME/standalone/tmp: auth

while in Wildfly 8 there was a single "auth" dir at top-level:

WILDFLY_HOME/auth

Apparently there is no changes to the code changing where the 'auth' directory is looked for so this may be an issue with the new build system (or was an issue with the old one, but that is not documented).  And as the code creates it if it does not exist this may have been unnoticed in either case.

We need to get this sorted out asap so we make sure these directories (or directory) are (or is) created with the right permissions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 15:38:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 9 Sep 2015 15:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5317) Upgrade to
 jboss-el-api_3.0_spec 1.0.5.Final
In-Reply-To: <JIRA.12584471.1441827468000@Atlassian.JIRA>
References: <JIRA.12584471.1441827468000@Atlassian.JIRA>
	<JIRA.12584471.1441827468762@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584471.1441827468000.17723.1441827480168@Atlassian.JIRA>

Scott Marlow created WFLY-5317:
----------------------------------

             Summary: Upgrade to jboss-el-api_3.0_spec 1.0.5.Final
                 Key: WFLY-5317
                 URL: https://issues.jboss.org/browse/WFLY-5317
             Project: WildFly
          Issue Type: Task
          Components: Server
            Reporter: Scott Marlow
            Assignee: Jason Greene
             Fix For: 10.0.0.CR1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 15:38:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 9 Sep 2015 15:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5317) Upgrade to
 jboss-el-api_3.0_spec 1.0.5.Final
In-Reply-To: <JIRA.12584471.1441827468000@Atlassian.JIRA>
References: <JIRA.12584471.1441827468000@Atlassian.JIRA>
	<JIRA.12584471.1441827468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584471.1441827468000.17727.1441827480294@Atlassian.JIRA>


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

Scott Marlow reassigned WFLY-5317:
----------------------------------

    Assignee: Scott Marlow  (was: Jason Greene)


> Upgrade to jboss-el-api_3.0_spec 1.0.5.Final
> --------------------------------------------
>
>                 Key: WFLY-5317
>                 URL: https://issues.jboss.org/browse/WFLY-5317
>             Project: WildFly
>          Issue Type: Task
>          Components: Server
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 15:45:00 2015
From: issues at jboss.org (Robert (Bob) Brodt (JIRA))
Date: Wed, 9 Sep 2015 15:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-910) Kie Navigator Server
 Property dialog does not save user creds
In-Reply-To: <JIRA.12584414.1441808297000@Atlassian.JIRA>
References: <JIRA.12584414.1441808297000@Atlassian.JIRA>
	<JIRA.12584414.1441808297000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584414.1441808297000.17763.1441827900125@Atlassian.JIRA>


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

Robert (Bob) Brodt reassigned DROOLS-910:
-----------------------------------------

    Assignee: Tomas David  (was: Robert (Bob) Brodt)


Tomas, this should be fixed in 6.3.0.Final

> Kie Navigator Server Property dialog does not save user creds
> -------------------------------------------------------------
>
>                 Key: DROOLS-910
>                 URL: https://issues.jboss.org/browse/DROOLS-910
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 6.3.0.CR2
>            Reporter: Robert (Bob) Brodt
>            Assignee: Tomas David
>             Fix For: 6.3.0.Final
>
>
> The Server Property dialog from Kie Navigator view does not save the username/password information and always defaults to admin/admin.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:13:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-471) pre/post cli-scripts for AS
 patching feature
In-Reply-To: <JIRA.12475775.1349017637000@Atlassian.JIRA>
References: <JIRA.12475775.1349017637000@Atlassian.JIRA>
	<JIRA.12475775.1349017637000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475775.1349017637000.17894.1441833180290@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-471:
------------------------------------
    Fix Version/s:     (was: 2.0.0.CR1)


> pre/post cli-scripts for AS patching feature
> --------------------------------------------
>
>                 Key: WFCORE-471
>                 URL: https://issues.jboss.org/browse/WFCORE-471
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Patching , Scripts
>            Reporter: Nicklas Karlsson
>            Assignee: Alexey Loubyansky
>
> It would be handy to be able to attach pre/post CLI scripts to be applied for an AS patch.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:14:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.17901.1441833240139@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-628:
------------------------------------
    Fix Version/s:     (was: 2.0.0.CR1)


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:14:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.17903.1441833240188@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-628:
------------------------------------
    Fix Version/s: 2.0.0.CR2


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:14:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.17906.1441833240233@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-909:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:15:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-403) Evaluate making operation
 "composite" EntryType.PUBLIC
In-Reply-To: <JIRA.12491057.1367612465000@Atlassian.JIRA>
References: <JIRA.12491057.1367612465000@Atlassian.JIRA>
	<JIRA.12491057.1367612465000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491057.1367612465000.17909.1441833301687@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-403:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR1)


> Evaluate making operation "composite" EntryType.PUBLIC
> ------------------------------------------------------
>
>                 Key: WFCORE-403
>                 URL: https://issues.jboss.org/browse/WFCORE-403
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha1
>
>
> When the composite operation handler is registered, it's marked as EntryType.PRIVATE. This operation really isn't private; any reasonable management client will need to invoke it.
> Changing it may have some implications though; we need to evaluate those. The biggest is the operation metadata cannot be complete, because the step parameter elements cannot be fully described.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:15:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.17912.1441833302626@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-459:
------------------------------------
    Fix Version/s: 3.0.0.Beta1
                       (was: 2.0.0.CR1)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 3.0.0.Beta1
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:18:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-970) Deploying a CLI archive that
 contains "module add" commands results in "WFLYCTL0155: steps may not be
 null" when using the CLI GUI
In-Reply-To: <JIRA.12568495.1429107543000@Atlassian.JIRA>
References: <JIRA.12568495.1429107543000@Atlassian.JIRA>
	<JIRA.12568495.1429107543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568495.1429107543000.17931.1441833480242@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-4520 to WFCORE-970:
-----------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-970  (was: WFLY-4520)
          Component/s: CLI
                           (was: CLI)
    Affects Version/s:     (was: 8.2.0.Final)
                           (was: 9.0.0.Beta2)


> Deploying a CLI archive that contains "module add" commands results in "WFLYCTL0155: steps may not be null" when using the CLI GUI
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-970
>                 URL: https://issues.jboss.org/browse/WFCORE-970
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Paul Newport
>            Assignee: Alexey Loubyansky
>         Attachments: install-mojarra-1.2_15.cli
>
>
> When using the CLI GUI to deploy a CLI archive that contains "module add" commands in its deploy.scr script, the following error message occurs:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0155: steps may not be null",
>     "rolled-back" => true
> }
> {code}
> The modules still get created successfully even though the above error messages appears. Note that this error only occurs when using the CLI GUI. Using the CLI without the --gui option works fine.
> Deploying the attached CLI archive using the CLI GUI will result in the above error message.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:24:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-971) Autocomplete not working for
 ha-policy names
In-Reply-To: <JIRA.12578551.1437382504000@Atlassian.JIRA>
References: <JIRA.12578551.1437382504000@Atlassian.JIRA>
	<JIRA.12578551.1437382504000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578551.1437382504000.17943.1441833840203@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-4963 to WFCORE-971:
-----------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-971  (was: WFLY-4963)
          Component/s: CLI
                           (was: CLI)
    Affects Version/s:     (was: 10.0.0.Alpha5)


> Autocomplete not working for ha-policy names
> --------------------------------------------
>
>                 Key: WFCORE-971
>                 URL: https://issues.jboss.org/browse/WFCORE-971
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Ond?ej Kalman
>            Assignee: Alexey Loubyansky
>
> When I try to configure ha-policy I have to use operation "read-resources-description" to get available names for ha-policies. User friendly solution is to auto complete this with tab and get all names when i type "./ha-policy= [TAB]"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep  9 17:30:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 9 Sep 2015 17:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.17997.1441834200379@Atlassian.JIRA>


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

Ken Wills commented on WFCORE-310:
----------------------------------

Updated from discussion yesterday (20150908):

- XML changes deferred to later release.
- ignore-unused no longer has a default in XSD.
- If --backup is used then ignore-unused is false if it is unspecified in XML
- if --backup is not specified, then ignore-unused is true
- if --backup is used and ignore-unused is true in XML, then it remains true.

> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR1
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 17:46:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 17:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5117) Switch to version 5 of the
 management schema
In-Reply-To: <JIRA.12581619.1439833645000@Atlassian.JIRA>
References: <JIRA.12581619.1439833645000@Atlassian.JIRA>
	<JIRA.12581619.1439833645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581619.1439833645000.18065.1441835160113@Atlassian.JIRA>


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

Brian Stansberry commented on WFLY-5117:
----------------------------------------

Why is there a WFLY issue for this?

> Switch to version 5 of the management schema
> --------------------------------------------
>
>                 Key: WFLY-5117
>                 URL: https://issues.jboss.org/browse/WFLY-5117
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 18:10:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 18:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.18091.1441836600174@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-4952 to WFCORE-972:
-----------------------------------------------

          Project: WildFly Core  (was: WildFly)
              Key: WFCORE-972  (was: WFLY-4952)
      Component/s: Domain Management
                       (was: Domain Management)
    Fix Version/s: 2.0.0.CR1
                       (was: 10.0.0.CR1)


> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 2.0.0.CR1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 18:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 18:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3500) JMX - Non string attributes
 dont work well with expressions & min/max
In-Reply-To: <JIRA.12543947.1402913834000@Atlassian.JIRA>
References: <JIRA.12543947.1402913834000@Atlassian.JIRA>
	<JIRA.12543947.1402913834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543947.1402913834000.18107.1441837680134@Atlassian.JIRA>


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

Brian Stansberry commented on WFLY-3500:
----------------------------------------

[~elguardian] Please make the preceding comment public.

> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3500
>                 URL: https://issues.jboss.org/browse/WFLY-3500
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: Tomaz Cerar
>            Assignee: Enrique Gonz?lez Mart?nez
>            Priority: Minor
>             Fix For: 10.0.0.CR1
>
>         Attachments: stacktrace.log
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep  9 18:41:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 18:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3500) JMX - Non string attributes
 dont work well with expressions & min/max
In-Reply-To: <JIRA.12543947.1402913834000@Atlassian.JIRA>
References: <JIRA.12543947.1402913834000@Atlassian.JIRA>
	<JIRA.12543947.1402913834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543947.1402913834000.18134.1441838460351@Atlassian.JIRA>


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

Brian Stansberry commented on WFLY-3500:
----------------------------------------

I don't see how this situation:

AD defined as INT (allows expressions)
{defaultValue :5, minValue = 4, maxValue= 10}

results in the attached stack trace.

MBeanInfoFactory.getParameterInfos doesn't try to store minValue or maxValue in the descriptor if the parameter supports expressions.

Please provide a test case that reproduces the problem, or a full failure report from a current test case.

> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3500
>                 URL: https://issues.jboss.org/browse/WFLY-3500
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: Tomaz Cerar
>            Assignee: Enrique Gonz?lez Mart?nez
>            Priority: Minor
>         Attachments: stacktrace.log
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep  9 18:41:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 18:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-973) JMX - Non string attributes
 dont work well with expressions & min/max
In-Reply-To: <JIRA.12543947.1402913834000@Atlassian.JIRA>
References: <JIRA.12543947.1402913834000@Atlassian.JIRA>
	<JIRA.12543947.1402913834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543947.1402913834000.18139.1441838460432@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-3500 to WFCORE-973:
-----------------------------------------------

          Project: WildFly Core  (was: WildFly)
              Key: WFCORE-973  (was: WFLY-3500)
      Component/s: Domain Management
                   JMX
                       (was: Domain Management)
                       (was: JMX)
    Fix Version/s:     (was: 10.0.0.CR1)


> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-973
>                 URL: https://issues.jboss.org/browse/WFCORE-973
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: Tomaz Cerar
>            Assignee: Enrique Gonz?lez Mart?nez
>            Priority: Minor
>         Attachments: stacktrace.log
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep  9 18:43:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 18:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-733) Expose tatletale management
	operations
In-Reply-To: <JIRA.12480560.1354777020000@Atlassian.JIRA>
References: <JIRA.12480560.1354777020000@Atlassian.JIRA>
	<JIRA.12480560.1354777020000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480560.1354777020000.18143.1441838580222@Atlassian.JIRA>


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

Brian Stansberry closed WFLY-733.
---------------------------------
    Resolution: Out of Date


Closing as HAL-359 is closed.

> Expose tatletale management operations
> --------------------------------------
>
>                 Key: WFLY-733
>                 URL: https://issues.jboss.org/browse/WFLY-733
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>             Fix For: Awaiting Volunteers
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 18:45:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 18:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-974) Cli calls leak memory in
 Host Controller when reading children names in domain mode
In-Reply-To: <JIRA.12577224.1436274389000@Atlassian.JIRA>
References: <JIRA.12577224.1436274389000@Atlassian.JIRA>
	<JIRA.12577224.1436274389000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577224.1436274389000.18148.1441838700245@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-4881 to WFCORE-974:
-----------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-974  (was: WFLY-4881)
          Component/s: Domain Management
                       Remoting
                           (was: Domain Management)
                           (was: Remoting)
    Affects Version/s:     (was: 8.1.0.Final)
                           (was: 8.2.0.Final)
                           (was: 9.0.0.Final)
        Fix Version/s: 2.0.0.CR1
                           (was: 10.0.0.CR1)


> Cli calls leak memory in Host Controller when reading children names in domain mode
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-974
>                 URL: https://issues.jboss.org/browse/WFCORE-974
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Remoting
>         Environment: CentOS 6.5:
> # java -version
> java version "1.7.0_79"
> OpenJDK Runtime Environment (rhel-2.5.5.2.el7_1-x86_64 u79-b14)
> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
> CentOS 7.0:
> # 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)
>            Reporter: Michael Noack
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>         Attachments: host-controller-jvm.png
>
>
> Calling the cli using the command:
> {{jboss-cli.sh --connect  --user="myuser" --password="mypassword" --command=":read-children-names(child-type=host)"}}
> leaks memory to old gen. Eventually the host controller goes OOM if called to often.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 18:55:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 18:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-975) Improve error reporting on
 misconfigured security-realm
In-Reply-To: <JIRA.12489453.1366020236000@Atlassian.JIRA>
References: <JIRA.12489453.1366020236000@Atlassian.JIRA>
	<JIRA.12489453.1366020236000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489453.1366020236000.18157.1441839300397@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-1018 to WFCORE-975:
-----------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-975  (was: WFLY-1018)
    Component/s: Domain Management
                 Security
                     (was: Domain Management)
                     (was: Security)


> Improve error reporting on misconfigured security-realm
> -------------------------------------------------------
>
>                 Key: WFCORE-975
>                 URL: https://issues.jboss.org/browse/WFCORE-975
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Alessio Soldano
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> I've erroneously configured standalone.xml with an empty (no child) security realm and referenced it in a undertow https listenerer.
> When running a test relying on https, I'm getting the following error only on server side:
> 11:43:44,482 ERROR [org.xnio.listener] (default I/O-3) A channel event listener threw an exception: java.lang.NullPointerException
> 	at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:143) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:288) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:285) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> 	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> 	at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.1.0.CR2.jar:3.1.0.CR2]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) [xnio-nio-3.1.0.CR2.jar:3.1.0.CR2]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 19:12:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 19:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1171) Global configuration for
 registering session filters, session timeouts etc
In-Reply-To: <JIRA.12489695.1366194967000@Atlassian.JIRA>
References: <JIRA.12489695.1366194967000@Atlassian.JIRA>
	<JIRA.12489695.1366194967000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489695.1366194967000.18179.1441840320505@Atlassian.JIRA>


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

Brian Stansberry updated WFLY-1171:
-----------------------------------
    Component/s: Web (Undertow)


> Global configuration for registering session filters, session timeouts etc
> --------------------------------------------------------------------------
>
>                 Key: WFLY-1171
>                 URL: https://issues.jboss.org/browse/WFLY-1171
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Nicklas Karlsson
>            Assignee: Tomaz Cerar
>
> It would be handy to have a mechanism for setting HTTP session timeouts, registering filters etc globally across all deployments. This concept could later on be expanded to cover global interceptors and similar. Perhaps in the form of web.xml/ejb-jar.xml files in a specific folder that would be merged at deployment time



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 19:12:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 19:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-976) Deployment fails with
 missing/unavailable dependencies
In-Reply-To: <JIRA.12564686.1425386008000@Atlassian.JIRA>
References: <JIRA.12564686.1425386008000@Atlassian.JIRA>
	<JIRA.12564686.1425386008000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564686.1425386008000.18182.1441840320572@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-4401 to WFCORE-976:
-----------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-976  (was: WFLY-4401)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s:     (was: 8.2.0.Final)


> Deployment fails with missing/unavailable dependencies
> ------------------------------------------------------
>
>                 Key: WFCORE-976
>                 URL: https://issues.jboss.org/browse/WFCORE-976
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Thomas Diesler
>            Assignee: Brian Stansberry
>
> Our testsuite bootstraps the server and then waits for the native management interface to become available on 8181
> A subsequent deployment (intermittently) fails with 
> {code}
> domain-master> [Host Controller] [0m[0m05:09:40,678 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /opt/jboss/wildfly/domain/data/content/ef/3743938a6b38a2ae473f12778fef7ad0ce464c/content[0m
> domain-slave> [Server:server-one] [0m[31m05:09:41,654 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 5) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "domain-endpoint.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"domain-endpoint.war\" is missing [jboss.deployment.chains]"]}[0m
> {code}
> There seems to be a missing guarantee that allows the management endpoint to answer deployment requests when the deployment chain services are not up.
> CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/175



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 20:02:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 20:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4433) Potential deadlock on server
	shutdown
In-Reply-To: <JIRA.12565951.1426498445000@Atlassian.JIRA>
References: <JIRA.12565951.1426498445000@Atlassian.JIRA>
	<JIRA.12565951.1426498445000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565951.1426498445000.18206.1441843320111@Atlassian.JIRA>


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

Brian Stansberry commented on WFLY-4433:
----------------------------------------

This doesn't look like a deadlock. I don't know how Thread-14 got invoked, but it's just waiting for Thread-13 to finish doing the same work. The pool-2-thread-1 reaper thread is also waiting for Thread-13. Neither are doing anything that prevents Thread-13 from progressing.

All the action here is with Thread-13, which has called close() on an org.jboss.remoting3.EndpointImpl and is waiting for asynchronous activity to notify the closeLock object.

This looks like a Remoting issue. Since this is WildFly 8.2 there a possibility it's already resolved. Perhaps https://issues.jboss.org/browse/REM3-183. Has this ever occured with WildFly 9 or 10?

> Potential deadlock on server shutdown
> -------------------------------------
>
>                 Key: WFLY-4433
>                 URL: https://issues.jboss.org/browse/WFLY-4433
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.2.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Brian Stansberry
>
> There is a rare condition where the server shutdown hangs forever. It may be related to the lock on 0x00000000c6ac9800
> {code}
> [0m[0m12:05:00,818 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment example-camel-activemq-2.2.0-SNAPSHOT.war (runtime-name: example-camel-activemq-2.2.0-SNAPSHOT.war) in 1783ms
> [0m[0m12:05:06,337 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment hawtio-1.4.42.war (runtime-name: hawtio-1.4.42.war) in 7281ms
> [0m[0m12:05:06,346 INFO  [org.jboss.as] (MSC service thread 1-3) JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 7297ms
> [0m2015-03-16 05:25:01
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode):
> "Thread-14" #38 daemon prio=5 os_prio=0 tid=0x00007f63b6708000 nid=0x13ad waiting for monitor entry [0x00007f6394154000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- waiting to lock <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "Thread-13" #37 daemon prio=5 os_prio=0 tid=0x00007f63b465f000 nid=0x13ab in Object.wait() [0x00007f63814d1000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
> 	- locked <0x00000000c6ac92b0> (a java.lang.Object)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.close(RemotingModelControllerClient.java:100)
> 	- locked <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.wildfly.plugin.common.IoUtils.safeClose(IoUtils.java:37)
> 	at org.wildfly.plugin.server.StandaloneServer.stopServer(StandaloneServer.java:77)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- locked <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "pool-2-thread-1" #45 prio=5 os_prio=0 tid=0x00007f63b5c43800 nid=0x110d waiting for monitor entry [0x00007f6394a5d000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:116)
> 	- waiting to lock <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.wildfly.plugin.server.StandaloneServer.checkServerState(StandaloneServer.java:149)
> 	at org.wildfly.plugin.server.Server$Reaper.run(Server.java:195)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 	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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep  9 22:23:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 22:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-60) Capabilities and requirements
 in a managed process
In-Reply-To: <JIRA.12549680.1408475027000@Atlassian.JIRA>
References: <JIRA.12549680.1408475027000@Atlassian.JIRA>
	<JIRA.12549680.1408475027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549680.1408475027000.18381.1441851780143@Atlassian.JIRA>


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

Brian Stansberry resolved WFCORE-60.
------------------------------------
    Resolution: Done


> Capabilities and requirements in a managed process
> --------------------------------------------------
>
>                 Key: WFCORE-60
>                 URL: https://issues.jboss.org/browse/WFCORE-60
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>
> Implement the aspects discussed under the "Runtime" section of https://community.jboss.org/docs/DOC-52712
> Add an API to the OperationContext for handlers to publish capabilities and for other handlers to register a requirement for those capabilities and to access the API object associated with the capability.
> The registry of capabilities and requirements should be maintained with a semantic equivalent to the resource tree. The registry is copied-on-write, making the copy invisible to concurrently executing operations, and then the copy is published on commit of the operation that modified it. If the operation does not commit, the copy is discarded, so handlers have no need to revert changes they make to the registry.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 22:33:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Sep 2015 22:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.18426.1441852380254@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-840:
-----------------------------------------

How did https://github.com/wildfly/wildfly-core/pull/1029 relate to this?

We need to track the dependencies between capabilities. Perhaps some other way will work, but since the resource that has this attribute can provide > 1 capability, or even in theory it could be a parent resource that provides the capability, in at least some cases we need some way to clarify the dependent side.

> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep  9 23:05:00 2015
From: issues at jboss.org (Richard Fontana (JIRA))
Date: Wed, 9 Sep 2015 23:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-911) Remove obsolete EULA
In-Reply-To: <JIRA.12584505.1441854243000@Atlassian.JIRA>
References: <JIRA.12584505.1441854243000@Atlassian.JIRA>
	<JIRA.12584505.1441854243391@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584505.1441854243000.18458.1441854300188@Atlassian.JIRA>

Richard Fontana created SECURITY-911:
----------------------------------------

             Summary: Remove obsolete EULA
                 Key: SECURITY-911
                 URL: https://issues.jboss.org/browse/SECURITY-911
             Project: PicketBox 
          Issue Type: Patch
            Reporter: Richard Fontana
            Assignee: Stefan Guilhen


The file JBossORG-EULA.txt appears twice in picketbox. This EULA file is obsolete and erroneous and should be deleted.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 01:26:00 2015
From: issues at jboss.org (Tomas David (JIRA))
Date: Thu, 10 Sep 2015 01:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-911) Kie Navigator does not
 recognize running EAP server
In-Reply-To: <JIRA.12584507.1441862729000@Atlassian.JIRA>
References: <JIRA.12584507.1441862729000@Atlassian.JIRA>
	<JIRA.12584507.1441862729986@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584507.1441862729000.18493.1441862760184@Atlassian.JIRA>

Tomas David created DROOLS-911:
----------------------------------

             Summary: Kie Navigator does not recognize running EAP server
                 Key: DROOLS-911
                 URL: https://issues.jboss.org/browse/DROOLS-911
             Project: Drools
          Issue Type: Bug
          Components: eclipse plugin
    Affects Versions: 6.3.0.CR2
            Reporter: Tomas David
            Assignee: Robert (Bob) Brodt


Kie Navigator does not recognize running EAP server. Server should be listed in Kie Navigator view but there is only default link ("No servers available. Click this link to create a new server...") to the Servers view.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 01:36:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 10 Sep 2015 01:36:00 -0400 (EDT)
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.18517.1441863360572@Atlassian.JIRA>


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

Amos Feng commented on WFLY-5224:
---------------------------------

[~maeste] can you take a look at this issue ?
After switching to use process-id-socket-bindings by
{code}
batch
/socket-binding-group=standard-sockets/socket-binding=txn-socket-process-id:add(port=4714)
/subsystem=transactions:undefine-attribute(name=process-id-uuid)
/subsystem=transactions:write-attribute(name=process-id-socket-binding,value=txn-socket-process-id)
run-batch --verbose
{code}

the read-resouce returns failed
{code}
[standalone at localhost:9990 /] /subsystem=transactions:read-resource
{
    "outcome" => "failed",
    "rolled-back" => true
}
{code}

I think that it might be related to the validation codes we are using to check the process-id-* attrubites
https://github.com/jbosstm/jboss-as/blob/5_BRANCH/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L346

I tried to comment the validateUpdateModel and it works that "read-resource" returns success. I noticed that the these validate codes added by you So can you give me some ideas to fix this issue. 
{code}
private static class ProcessIdWriteHandler extends ReloadRequiredWriteAttributeHandler {
    @Override
        protected void finishModelStage(final OperationContext context, final ModelNode operation, String attributeName,
                                        ModelNode newValue, ModelNode oldValue, final Resource model) throws OperationFailedException {
    ...
    // validateUpdatedModel(context, model);
   }
}
{code}

> 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: Amos Feng
>            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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 02:27:00 2015
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Petrovick=C3=BD_=28JIRA=29?=)
Date: Thu, 10 Sep 2015 02:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-910) Kie Navigator Server
 Property dialog does not save user creds
In-Reply-To: <JIRA.12584414.1441808297000@Atlassian.JIRA>
References: <JIRA.12584414.1441808297000@Atlassian.JIRA>
	<JIRA.12584414.1441808297000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584414.1441808297000.18568.1441866420217@Atlassian.JIRA>


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

Luk?? Petrovick? reassigned DROOLS-910:
---------------------------------------

    Assignee: Luk?? Petrovick?  (was: Tomas David)


> Kie Navigator Server Property dialog does not save user creds
> -------------------------------------------------------------
>
>                 Key: DROOLS-910
>                 URL: https://issues.jboss.org/browse/DROOLS-910
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 6.3.0.CR2
>            Reporter: Robert (Bob) Brodt
>            Assignee: Luk?? Petrovick?
>             Fix For: 6.3.0.Final
>
>
> The Server Property dialog from Kie Navigator view does not save the username/password information and always defaults to admin/admin.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 02:27:00 2015
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Petrovick=C3=BD_=28JIRA=29?=)
Date: Thu, 10 Sep 2015 02:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-910) Kie Navigator Server
 Property dialog does not save user creds
In-Reply-To: <JIRA.12584414.1441808297000@Atlassian.JIRA>
References: <JIRA.12584414.1441808297000@Atlassian.JIRA>
	<JIRA.12584414.1441808297000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584414.1441808297000.18571.1441866420318@Atlassian.JIRA>


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

Luk?? Petrovick? reassigned DROOLS-910:
---------------------------------------

    Assignee: Robert (Bob) Brodt  (was: Luk?? Petrovick?)


> Kie Navigator Server Property dialog does not save user creds
> -------------------------------------------------------------
>
>                 Key: DROOLS-910
>                 URL: https://issues.jboss.org/browse/DROOLS-910
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 6.3.0.CR2
>            Reporter: Robert (Bob) Brodt
>            Assignee: Robert (Bob) Brodt
>             Fix For: 6.3.0.Final
>
>
> The Server Property dialog from Kie Navigator view does not save the username/password information and always defaults to admin/admin.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 02:39:00 2015
From: issues at jboss.org (Tomas David (JIRA))
Date: Thu, 10 Sep 2015 02:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-910) Kie Navigator Server
 Property dialog does not save user creds
In-Reply-To: <JIRA.12584414.1441808297000@Atlassian.JIRA>
References: <JIRA.12584414.1441808297000@Atlassian.JIRA>
	<JIRA.12584414.1441808297000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584414.1441808297000.18581.1441867140241@Atlassian.JIRA>


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

Tomas David commented on DROOLS-910:
------------------------------------

I created bugzilla fo this issue https://bugzilla.redhat.com/show_bug.cgi?id=1261759

> Kie Navigator Server Property dialog does not save user creds
> -------------------------------------------------------------
>
>                 Key: DROOLS-910
>                 URL: https://issues.jboss.org/browse/DROOLS-910
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 6.3.0.CR2
>            Reporter: Robert (Bob) Brodt
>            Assignee: Robert (Bob) Brodt
>             Fix For: 6.3.0.Final
>
>
> The Server Property dialog from Kie Navigator view does not save the username/password information and always defaults to admin/admin.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 02:39:00 2015
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Thu, 10 Sep 2015 02:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4433) Potential deadlock on server
	shutdown
In-Reply-To: <JIRA.12565951.1426498445000@Atlassian.JIRA>
References: <JIRA.12565951.1426498445000@Atlassian.JIRA>
	<JIRA.12565951.1426498445000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565951.1426498445000.18584.1441867140307@Atlassian.JIRA>


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

Thomas Diesler reassigned WFLY-4433:
------------------------------------

    Assignee: Thomas Diesler  (was: Brian Stansberry)


> Potential deadlock on server shutdown
> -------------------------------------
>
>                 Key: WFLY-4433
>                 URL: https://issues.jboss.org/browse/WFLY-4433
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.2.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> There is a rare condition where the server shutdown hangs forever. It may be related to the lock on 0x00000000c6ac9800
> {code}
> [0m[0m12:05:00,818 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment example-camel-activemq-2.2.0-SNAPSHOT.war (runtime-name: example-camel-activemq-2.2.0-SNAPSHOT.war) in 1783ms
> [0m[0m12:05:06,337 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment hawtio-1.4.42.war (runtime-name: hawtio-1.4.42.war) in 7281ms
> [0m[0m12:05:06,346 INFO  [org.jboss.as] (MSC service thread 1-3) JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 7297ms
> [0m2015-03-16 05:25:01
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode):
> "Thread-14" #38 daemon prio=5 os_prio=0 tid=0x00007f63b6708000 nid=0x13ad waiting for monitor entry [0x00007f6394154000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- waiting to lock <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "Thread-13" #37 daemon prio=5 os_prio=0 tid=0x00007f63b465f000 nid=0x13ab in Object.wait() [0x00007f63814d1000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
> 	- locked <0x00000000c6ac92b0> (a java.lang.Object)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.close(RemotingModelControllerClient.java:100)
> 	- locked <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.wildfly.plugin.common.IoUtils.safeClose(IoUtils.java:37)
> 	at org.wildfly.plugin.server.StandaloneServer.stopServer(StandaloneServer.java:77)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- locked <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "pool-2-thread-1" #45 prio=5 os_prio=0 tid=0x00007f63b5c43800 nid=0x110d waiting for monitor entry [0x00007f6394a5d000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:116)
> 	- waiting to lock <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.wildfly.plugin.server.StandaloneServer.checkServerState(StandaloneServer.java:149)
> 	at org.wildfly.plugin.server.Server$Reaper.run(Server.java:195)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 	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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 02:40:00 2015
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Thu, 10 Sep 2015 02:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4433) Potential deadlock on server
	shutdown
In-Reply-To: <JIRA.12565951.1426498445000@Atlassian.JIRA>
References: <JIRA.12565951.1426498445000@Atlassian.JIRA>
	<JIRA.12565951.1426498445000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565951.1426498445000.18596.1441867200097@Atlassian.JIRA>


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

Thomas Diesler commented on WFLY-4433:
--------------------------------------

Thanks for following up on this - I'll verify.

> Potential deadlock on server shutdown
> -------------------------------------
>
>                 Key: WFLY-4433
>                 URL: https://issues.jboss.org/browse/WFLY-4433
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.2.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> There is a rare condition where the server shutdown hangs forever. It may be related to the lock on 0x00000000c6ac9800
> {code}
> [0m[0m12:05:00,818 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment example-camel-activemq-2.2.0-SNAPSHOT.war (runtime-name: example-camel-activemq-2.2.0-SNAPSHOT.war) in 1783ms
> [0m[0m12:05:06,337 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment hawtio-1.4.42.war (runtime-name: hawtio-1.4.42.war) in 7281ms
> [0m[0m12:05:06,346 INFO  [org.jboss.as] (MSC service thread 1-3) JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 7297ms
> [0m2015-03-16 05:25:01
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode):
> "Thread-14" #38 daemon prio=5 os_prio=0 tid=0x00007f63b6708000 nid=0x13ad waiting for monitor entry [0x00007f6394154000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- waiting to lock <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "Thread-13" #37 daemon prio=5 os_prio=0 tid=0x00007f63b465f000 nid=0x13ab in Object.wait() [0x00007f63814d1000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
> 	- locked <0x00000000c6ac92b0> (a java.lang.Object)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.close(RemotingModelControllerClient.java:100)
> 	- locked <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.wildfly.plugin.common.IoUtils.safeClose(IoUtils.java:37)
> 	at org.wildfly.plugin.server.StandaloneServer.stopServer(StandaloneServer.java:77)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- locked <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "pool-2-thread-1" #45 prio=5 os_prio=0 tid=0x00007f63b5c43800 nid=0x110d waiting for monitor entry [0x00007f6394a5d000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:116)
> 	- waiting to lock <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.wildfly.plugin.server.StandaloneServer.checkServerState(StandaloneServer.java:149)
> 	at org.wildfly.plugin.server.Server$Reaper.run(Server.java:195)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 	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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 02:42:00 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Thu, 10 Sep 2015 02:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.18600.1441867320146@Atlassian.JIRA>


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

?? ? commented on DROOLS-880:
-----------------------------

I test again using additional header. But still nothing show up.
Could you upload your test file?  (17:04:45,715 INFO [stdout] (default task-18) >>>>> TestVO = "MyVO1")

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 02:43:00 2015
From: issues at jboss.org (Tomas David (JIRA))
Date: Thu, 10 Sep 2015 02:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-911) Kie Navigator does not
 recognize running EAP server
In-Reply-To: <JIRA.12584507.1441862729000@Atlassian.JIRA>
References: <JIRA.12584507.1441862729000@Atlassian.JIRA>
	<JIRA.12584507.1441862729000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584507.1441862729000.18603.1441867380088@Atlassian.JIRA>


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

Tomas David commented on DROOLS-911:
------------------------------------

https://bugzilla.redhat.com/show_bug.cgi?id=1261762

> Kie Navigator does not recognize running EAP server
> ---------------------------------------------------
>
>                 Key: DROOLS-911
>                 URL: https://issues.jboss.org/browse/DROOLS-911
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 6.3.0.CR2
>            Reporter: Tomas David
>            Assignee: Robert (Bob) Brodt
>
> Kie Navigator does not recognize running EAP server. Server should be listed in Kie Navigator view but there is only default link ("No servers available. Click this link to create a new server...") to the Servers view.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 02:54:00 2015
From: issues at jboss.org (Andrei Bidi (JIRA))
Date: Thu, 10 Sep 2015 02:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-329) ClassFormatException when
 compile template with latest JDK8 (b114)
In-Reply-To: <JIRA.12524625.1383920786000@Atlassian.JIRA>
References: <JIRA.12524625.1383920786000@Atlassian.JIRA>
	<JIRA.12524625.1383920786000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524625.1383920786000.18629.1441868040673@Atlassian.JIRA>


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

Andrei Bidi commented on DROOLS-329:
------------------------------------

Still getting the error with both 6.3.0.CR1 & 6.3.0.RC2. Tried the ecj v 4.3.1, 4.4, 4.4.2, but it didn't help 

> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
>                 Key: DROOLS-329
>                 URL: https://issues.jboss.org/browse/DROOLS-329
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>         Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
>            Reporter: Marek Posolda
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.3.0.CR1
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main/java/org/drools/examples/templates/SimpleRuleTemplateExample.java )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> 	at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> 	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> 	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> 	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> 	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> 	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> 	at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> 	at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> 	at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> 	at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> 	at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> 	at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> 	at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> 	... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> 	at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> 	... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 03:24:00 2015
From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=)
Date: Thu, 10 Sep 2015 03:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-973) JMX - Non string attributes
 dont work well with expressions & min/max
In-Reply-To: <JIRA.12543947.1402913834000@Atlassian.JIRA>
References: <JIRA.12543947.1402913834000@Atlassian.JIRA>
	<JIRA.12543947.1402913834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543947.1402913834000.18655.1441869840227@Atlassian.JIRA>


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

Enrique Gonz?lez Mart?nez edited comment on WFCORE-973 at 9/10/15 3:23 AM:
---------------------------------------------------------------------------

Attached the stack trace.
The SimpleTypeConverter calculates the opentype as String if the AD allows an expression. That makes the situation odd for simple types.  
The consistency of the attributes is checked during the creation of the openmbean. If these conversions from simple types (INT) to strings take place and there is a min-max constraint, then it could throw an exception.

Example: 
AD defined as INT (allows expressions) {defaultValue :5, minValue = 4, maxValue= 10}
 
Those numbers are converted to Strings. That means the creation fails: defaultValue > maxValue (String comparison "5" > "10"). 

I cannot see a solution without overwriting the openmbean behavior (standard java rt lib).



> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-973
>                 URL: https://issues.jboss.org/browse/WFCORE-973
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: Tomaz Cerar
>            Assignee: Enrique Gonz?lez Mart?nez
>            Priority: Minor
>         Attachments: stacktrace.log
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 05:40:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 05:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5117) Switch to version 5 of the
 management schema
In-Reply-To: <JIRA.12581619.1439833645000@Atlassian.JIRA>
References: <JIRA.12581619.1439833645000@Atlassian.JIRA>
	<JIRA.12581619.1439833645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581619.1439833645000.18900.1441878000530@Atlassian.JIRA>


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

Darran Lofthouse commented on WFLY-5117:
----------------------------------------

Because after bumping core we need to bump all the tests in WildFly otherwise they read 4 and marshal 5.

> Switch to version 5 of the management schema
> --------------------------------------------
>
>                 Key: WFLY-5117
>                 URL: https://issues.jboss.org/browse/WFLY-5117
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 05:40:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 05:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5117) Switch to version 5 of the
 management schema
In-Reply-To: <JIRA.12581619.1439833645000@Atlassian.JIRA>
References: <JIRA.12581619.1439833645000@Atlassian.JIRA>
	<JIRA.12581619.1439833645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581619.1439833645000.18917.1441878001138@Atlassian.JIRA>


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

Darran Lofthouse updated WFLY-5117:
-----------------------------------
    Component/s: Test Suite


> Switch to version 5 of the management schema
> --------------------------------------------
>
>                 Key: WFLY-5117
>                 URL: https://issues.jboss.org/browse/WFLY-5117
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 05:53:00 2015
From: issues at jboss.org (Arto Huusko (JIRA))
Date: Thu, 10 Sep 2015 05:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5318) Resource files under META-INF
 not found by ClassLoader.getResources
In-Reply-To: <JIRA.12584531.1441878748000@Atlassian.JIRA>
References: <JIRA.12584531.1441878748000@Atlassian.JIRA>
	<JIRA.12584531.1441878748448@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584531.1441878748000.18930.1441878780156@Atlassian.JIRA>

Arto Huusko created WFLY-5318:
---------------------------------

             Summary: Resource files under META-INF not found by ClassLoader.getResources
                 Key: WFLY-5318
                 URL: https://issues.jboss.org/browse/WFLY-5318
             Project: WildFly
          Issue Type: Bug
          Components: Class Loading
    Affects Versions: 9.0.1.Final
            Reporter: Arto Huusko
            Assignee: David Lloyd


ClassLoader.getResources("META-INF/example.properties") returns only such resources that are available in JAR files that are deployed as EJB modules in the EAR.

That is, if a POJO JAR that has META-INF/example.properties is on the class path of an EJB session, and the session does (any of the following)

- Thread.currentThread().getContextClassLoader().getResources("META-INF/example.properties");
- getClass().getClassLoader().getResources("META-INF/example.properties");
- MySessionBean.class.getClassLoader().getResources("META-INF/example.properties");

then the resource from the POJO jar is not returned. Resource files with the requested name from all deployed EJB modules, however, are returned.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:08:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Sep 2015 06:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2692) infinite wait in
 BasicComponent#waitForComponentStart() causes server hang
In-Reply-To: <JIRA.12528446.1388224198000@Atlassian.JIRA>
References: <JIRA.12528446.1388224198000@Atlassian.JIRA>
	<JIRA.12528446.1388224198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528446.1388224198000.18962.1441879680169@Atlassian.JIRA>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1218542|https://bugzilla.redhat.com/show_bug.cgi?id=1218542] from ASSIGNED to CLOSED

> infinite wait in BasicComponent#waitForComponentStart() causes server hang
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2692
>                 URL: https://issues.jboss.org/browse/WFLY-2692
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Thomas Fr?hbeck
>              Labels: EE, MSC, hangs
>         Attachments: WFLY-2692_infiniteHang_stacktrace.log
>
>
> some error in deployment may cause infinite wait on BasicComponent#waitForComponentStart():
>      protected void waitForComponentStart() {
>         if (!gate) {
>             // Block until successful start
>             synchronized (this) {
>                while (!gate) {
>                     // TODO: check for failure condition
>                     try {
>                         wait();
>  
> The server life cycle management is completely blocked, no normal redeployment/shutdown will work!
> Please provide some remedy (e.g. timed wait and fail?), IMHO this is really _very_ distressing for a production ready system.
>  
> Sample stack trace:
> "MSC service thread 1-7" prio=10 tid=0x00007f6c60001800 nid=0x7af0 in Object.wait() [0x00007f6cbd785000]
>    java.lang.Thread.State: WAITING (on object monitor)
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
>         at java.lang.Object.wait(Object.java:503)
>         at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:115)
>         - locked <0x00000000e20a0a20> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
>         at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:145)
>         at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:133)
>         at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
>         at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:123)
>         - locked <0x00000000e20bfa10> (a java.lang.Object)
>         at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterce
> ptor.java:47)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
>         at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 06:18:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.18967.1441880280443@Atlassian.JIRA>


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

Tomaz Cerar commented on WFCORE-840:
------------------------------------

It somewhat relates, as api for automatic registration of capabilities that are defined on RD was added.

Which was also one of the things that help fix this.
with current state of API one can register as many capabilities he wants, even if they are not related to single attribute.



> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:25:00 2015
From: issues at jboss.org (Dan Berindei (JIRA))
Date: Thu, 10 Sep 2015 06:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1964) OSGi support: Incorrect
 execution environment name
In-Reply-To: <JIRA.12584535.1441880698000@Atlassian.JIRA>
References: <JIRA.12584535.1441880698000@Atlassian.JIRA>
	<JIRA.12584535.1441880698416@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584535.1441880698000.19029.1441880700164@Atlassian.JIRA>

Dan Berindei created JGRP-1964:
----------------------------------

             Summary: OSGi support: Incorrect execution environment name
                 Key: JGRP-1964
                 URL: https://issues.jboss.org/browse/JGRP-1964
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.6.6
            Reporter: Dan Berindei
            Assignee: Bela Ban


The {{Bundle-RequiredExecutionEnvironment}} changed in 3.6.5.Final from J2SE-1.6 to Java2SE-1.7.

The list of supported execution environments depends on the container, but these are supported more or less everywhere: [http://www.osgi.org/Specifications/Reference]

J2SE-1.6 wasn't on the list either, but it worked with Apache Felix. Java2SE-1.7 doesn't work, so it should be replaced with the standard {{JavaSE-1.7}}.






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:29:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 10 Sep 2015 06:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1948)
 Bundle-RequiredExecutionEnvironment is set to unsupported value J2SE-1.6,
 should be JavaSE-1.6
In-Reply-To: <JIRA.12580168.1438612667000@Atlassian.JIRA>
References: <JIRA.12580168.1438612667000@Atlassian.JIRA>
	<JIRA.12580168.1438612667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580168.1438612667000.19038.1441880940133@Atlassian.JIRA>


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

Bela Ban commented on JGRP-1948:
--------------------------------

Paul, apparently that's wrong, the name should be JavaSE-1.7 (no '2'). Dan's creating another JIRA as we speak...

> Bundle-RequiredExecutionEnvironment is set to unsupported value J2SE-1.6, should be JavaSE-1.6
> ----------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1948
>                 URL: https://issues.jboss.org/browse/JGRP-1948
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.4
>            Reporter: Paul Illingworth
>            Assignee: Bela Ban
>              Labels: Manifest.mf, OSGi
>             Fix For: 3.6.5
>
>
> In the MANFEST.MF file the header Bundle-RequiredExecutionEnvironment is set to J2SE-1.6 which is a non standard value. The correct value shoud be Java2SE-1.6. 
> See http://wiki.osgi.org/wiki/Execution_Environment
> This is preventing the bundle from being loaded into my OSGi container (Felix).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:30:00 2015
From: issues at jboss.org (Dan Berindei (JIRA))
Date: Thu, 10 Sep 2015 06:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1964) OSGi support: Incorrect
 execution environment name
In-Reply-To: <JIRA.12584535.1441880698000@Atlassian.JIRA>
References: <JIRA.12584535.1441880698000@Atlassian.JIRA>
	<JIRA.12584535.1441880698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584535.1441880698000.19041.1441881000183@Atlassian.JIRA>


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

Dan Berindei commented on JGRP-1964:
------------------------------------

JGRP-1948 mentioned {{Java2SE-1.6}}, but that's not correct either - the newer versions don't have the '2'.

> OSGi support: Incorrect execution environment name
> --------------------------------------------------
>
>                 Key: JGRP-1964
>                 URL: https://issues.jboss.org/browse/JGRP-1964
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.6
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>
> The {{Bundle-RequiredExecutionEnvironment}} changed in 3.6.5.Final from J2SE-1.6 to Java2SE-1.7.
> The list of supported execution environments depends on the container, but these are supported more or less everywhere: [http://www.osgi.org/Specifications/Reference]
> J2SE-1.6 wasn't on the list either, but it worked with Apache Felix. Java2SE-1.7 doesn't work, so it should be replaced with the standard {{JavaSE-1.7}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:33:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 10 Sep 2015 06:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1964) OSGi support: Incorrect
 execution environment name
In-Reply-To: <JIRA.12584535.1441880698000@Atlassian.JIRA>
References: <JIRA.12584535.1441880698000@Atlassian.JIRA>
	<JIRA.12584535.1441880698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584535.1441880698000.19051.1441881180237@Atlassian.JIRA>


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

Bela Ban resolved JGRP-1964.
----------------------------
    Resolution: Done


> OSGi support: Incorrect execution environment name
> --------------------------------------------------
>
>                 Key: JGRP-1964
>                 URL: https://issues.jboss.org/browse/JGRP-1964
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.6
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>
> The {{Bundle-RequiredExecutionEnvironment}} changed in 3.6.5.Final from J2SE-1.6 to Java2SE-1.7.
> The list of supported execution environments depends on the container, but these are supported more or less everywhere: [http://www.osgi.org/Specifications/Reference]
> J2SE-1.6 wasn't on the list either, but it worked with Apache Felix. Java2SE-1.7 doesn't work, so it should be replaced with the standard {{JavaSE-1.7}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:33:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 10 Sep 2015 06:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1964) OSGi support: Incorrect
 execution environment name
In-Reply-To: <JIRA.12584535.1441880698000@Atlassian.JIRA>
References: <JIRA.12584535.1441880698000@Atlassian.JIRA>
	<JIRA.12584535.1441880698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584535.1441880698000.19055.1441881180495@Atlassian.JIRA>


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

Bela Ban updated JGRP-1964:
---------------------------
    Fix Version/s: 3.6.7


> OSGi support: Incorrect execution environment name
> --------------------------------------------------
>
>                 Key: JGRP-1964
>                 URL: https://issues.jboss.org/browse/JGRP-1964
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.6
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.6.7
>
>
> The {{Bundle-RequiredExecutionEnvironment}} changed in 3.6.5.Final from J2SE-1.6 to Java2SE-1.7.
> The list of supported execution environments depends on the container, but these are supported more or less everywhere: [http://www.osgi.org/Specifications/Reference]
> J2SE-1.6 wasn't on the list either, but it worked with Apache Felix. Java2SE-1.7 doesn't work, so it should be replaced with the standard {{JavaSE-1.7}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:42:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 06:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.19097.1441881720255@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-840:
-----------------------------------------

What I still don't understand is why the attribute definition needs to contain the dependent capability.  The resource has already declared the capabilities it provides so those should automatically be used as the dependent capability IMO.

> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:43:00 2015
From: issues at jboss.org (Maciej Swiderski (JIRA))
Date: Thu, 10 Sep 2015 06:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-908) Class load error with
 slf4j-api on Tomcat8
In-Reply-To: <JIRA.12584404.1441804062000@Atlassian.JIRA>
References: <JIRA.12584404.1441804062000@Atlassian.JIRA>
	<JIRA.12584404.1441804062000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584404.1441804062000.19101.1441881780240@Atlassian.JIRA>


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

Maciej Swiderski commented on DROOLS-908:
-----------------------------------------

Timo,

one question why you try to deploy ee7 version of kie server on tomcat instead of webc (which is tailored for web containers)? Our tests do not show any issues when running on current version of kie server webc on top of tomcat with slf4j api and slf4j-jdk14 being in tomcat/lib folder.

> Class load error with slf4j-api on Tomcat8
> ------------------------------------------
>
>                 Key: DROOLS-908
>                 URL: https://issues.jboss.org/browse/DROOLS-908
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR2
>         Environment: apache-tomcat-8.0.26
>            Reporter: Timo Riikonen
>            Assignee: Edson Tirelli
>
> Installation instructions request that slf4j-api JAR file is copied to Tomcats lib directory. And correctly also as the Tomcat won't start if it is not in there.
> But then this API conflicts with the same API in kie-server-6.3.0.CR2-ee7.
> I did a quick fix that seemed to solve this:
> # Removed kie-server WAR file from tomcat webapps directory, so that it won't undo the next step.
> # Deleted the problem file webapps/kie-server-6.3.0.CR2-ee7/WEB-INF/lib/slf4j-api-1.7.2.jar
> I considered removing the jar file from Drools project, but that is likely to cause other errors, so I decided to leave this to the experts (= you guys).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 06:52:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 06:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3330) Support
	enabled-cipher-suites="ALL"
In-Reply-To: <JIRA.12540344.1399643221000@Atlassian.JIRA>
References: <JIRA.12540344.1399643221000@Atlassian.JIRA>
	<JIRA.12540344.1399643221000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540344.1399643221000.19149.1441882320332@Atlassian.JIRA>


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

Darran Lofthouse commented on WFLY-3330:
----------------------------------------

Yes the Jira issue is marked Open / Unresolved.

> Support enabled-cipher-suites="ALL" 
> ------------------------------------
>
>                 Key: WFLY-3330
>                 URL: https://issues.jboss.org/browse/WFLY-3330
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.CR1
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> If I want to enable all ciphers format except MD5 I would have to specify a long list of all supported ciphers.
> Using the "ALL" keyword with a list of excluded elements this becomes easy to configure.
> The expected fopattern would be ALL:!ELT1:!ELT2
> Thus ALL:!MD5 would enable all supported ciphers except MD5.
> This is based on OpenSSL syntax for ciphers https://www.openssl.org/docs/apps/ciphers.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 07:45:00 2015
From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=)
Date: Thu, 10 Sep 2015 07:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-973) JMX - Non string attributes
 dont work well with expressions & min/max
In-Reply-To: <JIRA.12543947.1402913834000@Atlassian.JIRA>
References: <JIRA.12543947.1402913834000@Atlassian.JIRA>
	<JIRA.12543947.1402913834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543947.1402913834000.19273.1441885500291@Atlassian.JIRA>


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

Enrique Gonz?lez Mart?nez commented on WFCORE-973:
--------------------------------------------------

Hi [~brian.stansberry]

The example is already in the test case of JMX.  You need to uncomment a few things in the test case:

https://github.com/wildfly/wildfly-core/blob/2.0.0.Beta2/jmx/src/test/java/org/jboss/as/jmx/ModelControllerMBeanTestCase.java#L290
https://github.com/wildfly/wildfly-core/blob/2.0.0.Beta2/jmx/src/test/java/org/jboss/as/jmx/ModelControllerResourceDefinition.java#L211

I think the problem is in here (type converter is not taking into account the allowed expressions var of the model)
https://github.com/wildfly/wildfly-core/blob/2.0.0.Beta2/jmx/src/main/java/org/jboss/as/jmx/model/MBeanInfoFactory.java#L298

This returns AD string opentype as the type converter allows expressions ???? 
https://github.com/wildfly/wildfly-core/blob/2.0.0.Beta2/jmx/src/main/java/org/jboss/as/jmx/model/TypeConverters.java#L154
(variable expressions in TypeConverter object is true ->  all values for the openmbean will be converted)

After that it fails to construct the openmbean information. (OpenMBeanParameterInfoSupport). The opentype is String so default values are converted from INT to STRING.

It only happens with param4 because it is the only one with default value
https://github.com/wildfly/wildfly-core/blob/2.0.0.Beta2/jmx/src/test/java/org/jboss/as/jmx/ModelControllerResourceDefinition.java#L210

I hope this helps.



> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-973
>                 URL: https://issues.jboss.org/browse/WFCORE-973
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: Tomaz Cerar
>            Assignee: Enrique Gonz?lez Mart?nez
>            Priority: Minor
>         Attachments: stacktrace.log
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 07:46:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 10 Sep 2015 07:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5318) Resource files under META-INF
 not found by ClassLoader.getResources
In-Reply-To: <JIRA.12584531.1441878748000@Atlassian.JIRA>
References: <JIRA.12584531.1441878748000@Atlassian.JIRA>
	<JIRA.12584531.1441878748000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584531.1441878748000.19278.1441885560253@Atlassian.JIRA>


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

David Lloyd resolved WFLY-5318.
-------------------------------
    Resolution: Rejected


This is a usage problem.  If you want to include META-INF resources, you must declare that fact in a jboss-deployment-structure.xml descriptor for the consuming deployment JAR.

> Resource files under META-INF not found by ClassLoader.getResources
> -------------------------------------------------------------------
>
>                 Key: WFLY-5318
>                 URL: https://issues.jboss.org/browse/WFLY-5318
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 9.0.1.Final
>            Reporter: Arto Huusko
>            Assignee: David Lloyd
>
> ClassLoader.getResources("META-INF/example.properties") returns only such resources that are available in JAR files that are deployed as EJB modules in the EAR.
> That is, if a POJO JAR that has META-INF/example.properties is on the class path of an EJB session, and the session does (any of the following)
> - Thread.currentThread().getContextClassLoader().getResources("META-INF/example.properties");
> - getClass().getClassLoader().getResources("META-INF/example.properties");
> - MySessionBean.class.getClassLoader().getResources("META-INF/example.properties");
> then the resource from the POJO jar is not returned. Resource files with the requested name from all deployed EJB modules, however, are returned.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 08:00:03 2015
From: issues at jboss.org (Timo Riikonen (JIRA))
Date: Thu, 10 Sep 2015 08:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-908) Class load error with
 slf4j-api on Tomcat8
In-Reply-To: <JIRA.12584404.1441804062000@Atlassian.JIRA>
References: <JIRA.12584404.1441804062000@Atlassian.JIRA>
	<JIRA.12584404.1441804062000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584404.1441804062000.19339.1441886403157@Atlassian.JIRA>


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

Timo Riikonen commented on DROOLS-908:
--------------------------------------

Reason: Lack of understanding.
I'll remove the issue.


> Class load error with slf4j-api on Tomcat8
> ------------------------------------------
>
>                 Key: DROOLS-908
>                 URL: https://issues.jboss.org/browse/DROOLS-908
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR2
>         Environment: apache-tomcat-8.0.26
>            Reporter: Timo Riikonen
>            Assignee: Edson Tirelli
>
> Installation instructions request that slf4j-api JAR file is copied to Tomcats lib directory. And correctly also as the Tomcat won't start if it is not in there.
> But then this API conflicts with the same API in kie-server-6.3.0.CR2-ee7.
> I did a quick fix that seemed to solve this:
> # Removed kie-server WAR file from tomcat webapps directory, so that it won't undo the next step.
> # Deleted the problem file webapps/kie-server-6.3.0.CR2-ee7/WEB-INF/lib/slf4j-api-1.7.2.jar
> I considered removing the jar file from Drools project, but that is likely to cause other errors, so I decided to leave this to the experts (= you guys).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 08:01:00 2015
From: issues at jboss.org (Timo Riikonen (JIRA))
Date: Thu, 10 Sep 2015 08:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-908) Class load error with
 slf4j-api on Tomcat8
In-Reply-To: <JIRA.12584404.1441804062000@Atlassian.JIRA>
References: <JIRA.12584404.1441804062000@Atlassian.JIRA>
	<JIRA.12584404.1441804062000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584404.1441804062000.19346.1441886460238@Atlassian.JIRA>


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

Timo Riikonen closed DROOLS-908.
--------------------------------
    Docs QE Status:   (was: NEW)
     Fix Version/s: 6.3.0.Final
        Resolution: Rejected


> Class load error with slf4j-api on Tomcat8
> ------------------------------------------
>
>                 Key: DROOLS-908
>                 URL: https://issues.jboss.org/browse/DROOLS-908
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR2
>         Environment: apache-tomcat-8.0.26
>            Reporter: Timo Riikonen
>            Assignee: Edson Tirelli
>             Fix For: 6.3.0.Final
>
>
> Installation instructions request that slf4j-api JAR file is copied to Tomcats lib directory. And correctly also as the Tomcat won't start if it is not in there.
> But then this API conflicts with the same API in kie-server-6.3.0.CR2-ee7.
> I did a quick fix that seemed to solve this:
> # Removed kie-server WAR file from tomcat webapps directory, so that it won't undo the next step.
> # Deleted the problem file webapps/kie-server-6.3.0.CR2-ee7/WEB-INF/lib/slf4j-api-1.7.2.jar
> I considered removing the jar file from Drools project, but that is likely to cause other errors, so I decided to leave this to the experts (= you guys).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 08:12:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Sep 2015 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319)
 org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
 should guard against javax.transaction.RollbackException
In-Reply-To: <JIRA.12584552.1441887103000@Atlassian.JIRA>
References: <JIRA.12584552.1441887103000@Atlassian.JIRA>
	<JIRA.12584552.1441887103043@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584552.1441887103000.19365.1441887120184@Atlassian.JIRA>

Scott Marlow created WFLY-5319:
----------------------------------

             Summary: org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest should guard against javax.transaction.RollbackException
                 Key: WFLY-5319
                 URL: https://issues.jboss.org/browse/WFLY-5319
             Project: WildFly
          Issue Type: Feature Request
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 10.0.0.CR1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 08:32:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Sep 2015 08:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix
 org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
 failure
In-Reply-To: <JIRA.12584552.1441887103000@Atlassian.JIRA>
References: <JIRA.12584552.1441887103000@Atlassian.JIRA>
	<JIRA.12584552.1441887103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584552.1441887103000.19475.1441888320851@Atlassian.JIRA>


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

Scott Marlow updated WFLY-5319:
-------------------------------
    Summary: fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure  (was: org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest should guard against javax.transaction.RollbackException)


> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5319
>                 URL: https://issues.jboss.org/browse/WFLY-5319
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 08:32:01 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 10 Sep 2015 08:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-329) ClassFormatException when
 compile template with latest JDK8 (b114)
In-Reply-To: <JIRA.12524625.1383920786000@Atlassian.JIRA>
References: <JIRA.12524625.1383920786000@Atlassian.JIRA>
	<JIRA.12524625.1383920786000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524625.1383920786000.19496.1441888321344@Atlassian.JIRA>


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

Mario Fusco commented on DROOLS-329:
------------------------------------

Keep saying that it doesn't work without a reproducer is not really helpful. Can anybody provide one?

> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
>                 Key: DROOLS-329
>                 URL: https://issues.jboss.org/browse/DROOLS-329
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>         Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
>            Reporter: Marek Posolda
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.3.0.CR1
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main/java/org/drools/examples/templates/SimpleRuleTemplateExample.java )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> 	at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> 	at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> 	at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> 	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> 	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> 	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> 	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> 	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> 	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> 	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> 	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> 	at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> 	at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> 	at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> 	at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> 	at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> 	at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> 	at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> 	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> 	at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> 	... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> 	at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> 	at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> 	... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 08:33:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Sep 2015 08:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix
 org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
 failure
In-Reply-To: <JIRA.12584552.1441887103000@Atlassian.JIRA>
References: <JIRA.12584552.1441887103000@Atlassian.JIRA>
	<JIRA.12584552.1441887103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584552.1441887103000.19503.1441888380244@Atlassian.JIRA>


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

Scott Marlow updated WFLY-5319:
-------------------------------
    Description: https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception


> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5319
>                 URL: https://issues.jboss.org/browse/WFLY-5319
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 08:57:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Sep 2015 08:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix
 org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
 failure
In-Reply-To: <JIRA.12584552.1441887103000@Atlassian.JIRA>
References: <JIRA.12584552.1441887103000@Atlassian.JIRA>
	<JIRA.12584552.1441887103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584552.1441887103000.19591.1441889820120@Atlassian.JIRA>


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

Scott Marlow commented on WFLY-5319:
------------------------------------

one possible cause is if transactionSynchronizationRegistry.getTransactionKey() returns null in the TM reaper thread.

> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5319
>                 URL: https://issues.jboss.org/browse/WFLY-5319
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 09:33:00 2015
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 10 Sep 2015 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml
 resource in the released JGroups jar
In-Reply-To: <JIRA.12584316.1441751776000@Atlassian.JIRA>
References: <JIRA.12584316.1441751776000@Atlassian.JIRA>
	<JIRA.12584316.1441751776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584316.1441751776000.19714.1441891980072@Atlassian.JIRA>


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

Sanne Grinovero commented on JGRP-1962:
---------------------------------------

You can keep it in your project among the tests, but it doesn't have to be included in the released jar.
(On top of that, I'm not sure it's useful to include the README and all other resources: I think the fatten the jar without much benefit)

People can use the property you suggest, but unless I know that you're bundling the file (and even using the default resource name! ) I will assume that it's enough to add a {{log4j2.xml}} to my classpath and be set. It was painful debugging to figure out why it wasn't being effective.

> Do not include the log4j2.xml resource in the released JGroups jar
> ------------------------------------------------------------------
>
>                 Key: JGRP-1962
>                 URL: https://issues.jboss.org/browse/JGRP-1962
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.6.4
>            Reporter: Sanne Grinovero
>            Assignee: Bela Ban
>             Fix For: 3.6.6
>
>
> The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 09:37:00 2015
From: issues at jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 10 Sep 2015 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.19724.1441892220138@Atlassian.JIRA>


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

Jean-Frederic Clere commented on JBMETA-387:
--------------------------------------------

I have merged https://github.com/jboss/metadata/pull/89

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 09:41:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Sep 2015 09:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-158) EL 3 LambdaExpression failing
 with an exception irreversibly pollutes variable scope
In-Reply-To: <JIRA.12566693.1427190705000@Atlassian.JIRA>
References: <JIRA.12566693.1427190705000@Atlassian.JIRA>
	<JIRA.12566693.1427190705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566693.1427190705000.19733.1441892460268@Atlassian.JIRA>


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

Tomaz Cerar updated JBEE-158:
-----------------------------
    Git Pull Request: https://github.com/jboss/jboss-el-api_spec/pull/14


> EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
> ------------------------------------------------------------------------------------
>
>                 Key: JBEE-158
>                 URL: https://issues.jboss.org/browse/JBEE-158
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>    Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
>            Reporter: Paul Pogonyshev
>            Assignee: Tomaz Cerar
>              Labels: el-expresion, patch
>         Attachments: lambda-expression-scoping-fix.diff
>
>
> When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below.
> Test case:
> {noformat}
>         ELProcessor  processor = new ELProcessor ();
>         processor.defineBean ("x", null);
>         try {
>             processor.eval ("(x -> x.bug ()) ('bug')");
>         }
>         catch (RuntimeException exception) {
>             // This is expected, there is no method bug() on strings.
>         }
>         processor.eval ("x");  // This must evaluate to null, but instead evaluates to "bug".
> {noformat}
> Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 09:41:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Sep 2015 09:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-158) EL 3 LambdaExpression failing
 with an exception irreversibly pollutes variable scope
In-Reply-To: <JIRA.12566693.1427190705000@Atlassian.JIRA>
References: <JIRA.12566693.1427190705000@Atlassian.JIRA>
	<JIRA.12566693.1427190705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566693.1427190705000.19737.1441892460403@Atlassian.JIRA>


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

Tomaz Cerar commented on JBEE-158:
----------------------------------

send PR to fix this https://github.com/jboss/jboss-el-api_spec/pull/14

> EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
> ------------------------------------------------------------------------------------
>
>                 Key: JBEE-158
>                 URL: https://issues.jboss.org/browse/JBEE-158
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>    Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
>            Reporter: Paul Pogonyshev
>            Assignee: Tomaz Cerar
>              Labels: el-expresion, patch
>         Attachments: lambda-expression-scoping-fix.diff
>
>
> When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below.
> Test case:
> {noformat}
>         ELProcessor  processor = new ELProcessor ();
>         processor.defineBean ("x", null);
>         try {
>             processor.eval ("(x -> x.bug ()) ('bug')");
>         }
>         catch (RuntimeException exception) {
>             // This is expected, there is no method bug() on strings.
>         }
>         processor.eval ("x");  // This must evaluate to null, but instead evaluates to "bug".
> {noformat}
> Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 09:41:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Thu, 10 Sep 2015 09:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.19743.1441892460535@Atlassian.JIRA>


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

Ladislav Thon commented on JBMETA-387:
--------------------------------------

Thanks. I think this can be resolved/closed. [~pferraro], agreed?

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 09:43:00 2015
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Thu, 10 Sep 2015 09:43:00 -0400 (EDT)
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.19748.1441892580393@Atlassian.JIRA>


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

Stefano Maestri commented on WFLY-5224:
---------------------------------------

Problem solved w/ linked pull request. Please note the batch need to be modified as:


{code:java}
batch
/socket-binding-group=standard-sockets/socket-binding=txn-socket-process-id:add(port=4714)
/subsystem=transactions:write-attribute(name=process-id-socket-binding,value=txn-socket-process-id)
/subsystem=transactions:undefine-attribute(name=process-id-uuid)
run-batch --verbose
{code}

switching line 3 and 4

regards
S.

> 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: Amos Feng
>            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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 09:44:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Sep 2015 09:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-16) Introduce "version" to all
	operations
In-Reply-To: <JIRA.12474756.1347978678000@Atlassian.JIRA>
References: <JIRA.12474756.1347978678000@Atlassian.JIRA>
	<JIRA.12474756.1347978678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474756.1347978678000.19756.1441892640237@Atlassian.JIRA>


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

Tomaz Cerar reassigned WFCORE-16:
---------------------------------

    Assignee:     (was: Tomaz Cerar)


> Introduce "version" to all operations
> -------------------------------------
>
>                 Key: WFCORE-16
>                 URL: https://issues.jboss.org/browse/WFCORE-16
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>
> To better support backward compatibility for upcoming version of AS/mgmt api
> For start we should probably just send mgmt version of subsystem/core 
> in future we could use this info to route operations properly 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:10:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Sep 2015 10:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-158) EL 3 LambdaExpression failing
 with an exception irreversibly pollutes variable scope
In-Reply-To: <JIRA.12566693.1427190705000@Atlassian.JIRA>
References: <JIRA.12566693.1427190705000@Atlassian.JIRA>
	<JIRA.12566693.1427190705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566693.1427190705000.19901.1441894200534@Atlassian.JIRA>


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

Scott Marlow updated JBEE-158:
------------------------------
    Fix Version/s: jboss-el-api_3.0_spec-1.0.6.Final


> EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
> ------------------------------------------------------------------------------------
>
>                 Key: JBEE-158
>                 URL: https://issues.jboss.org/browse/JBEE-158
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>    Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
>            Reporter: Paul Pogonyshev
>            Assignee: Tomaz Cerar
>              Labels: el-expresion, patch
>             Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
>         Attachments: lambda-expression-scoping-fix.diff
>
>
> When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below.
> Test case:
> {noformat}
>         ELProcessor  processor = new ELProcessor ();
>         processor.defineBean ("x", null);
>         try {
>             processor.eval ("(x -> x.bug ()) ('bug')");
>         }
>         catch (RuntimeException exception) {
>             // This is expected, there is no method bug() on strings.
>         }
>         processor.eval ("x");  // This must evaluate to null, but instead evaluates to "bug".
> {noformat}
> Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:12:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Sep 2015 10:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-158) EL 3 LambdaExpression failing
 with an exception irreversibly pollutes variable scope
In-Reply-To: <JIRA.12566693.1427190705000@Atlassian.JIRA>
References: <JIRA.12566693.1427190705000@Atlassian.JIRA>
	<JIRA.12566693.1427190705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566693.1427190705000.19921.1441894320640@Atlassian.JIRA>


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

Tomaz Cerar resolved JBEE-158.
------------------------------
    Resolution: Done


> EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
> ------------------------------------------------------------------------------------
>
>                 Key: JBEE-158
>                 URL: https://issues.jboss.org/browse/JBEE-158
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-el-api
>    Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
>            Reporter: Paul Pogonyshev
>            Assignee: Tomaz Cerar
>              Labels: el-expresion, patch
>             Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
>         Attachments: lambda-expression-scoping-fix.diff
>
>
> When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below.
> Test case:
> {noformat}
>         ELProcessor  processor = new ELProcessor ();
>         processor.defineBean ("x", null);
>         try {
>             processor.eval ("(x -> x.bug ()) ('bug')");
>         }
>         catch (RuntimeException exception) {
>             // This is expected, there is no method bug() on strings.
>         }
>         processor.eval ("x");  // This must evaluate to null, but instead evaluates to "bug".
> {noformat}
> Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:12:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 10:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.19931.1441894320990@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-840:
-----------------------------------------

I'm going to "reject" the pull request just to get this into the correct state. Unfortunately, JIRA is now "helping" us manage issue state transitions by scanning commit messages in PRs, so please be cautious about referencing JIRA #s if the commit doesn't actually resolve the issue.

If a resource provides 2 capabilities, and its config includes a model ref attribute is only relevant to one, then it is incorrect to record that both capabilities require the dependee.

I'm going to unschedule this. It's an interesting thing to consider, but not a current priority.

> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:12:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 10:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.19935.1441894321254@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-840:
------------------------------------
    Fix Version/s:     (was: 2.0.0.CR1)


> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:13:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 10 Sep 2015 10:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-904) Trait proxy classes are not
 restored on persistent session deserialization
In-Reply-To: <JIRA.12584081.1441412121000@Atlassian.JIRA>
References: <JIRA.12584081.1441412121000@Atlassian.JIRA>
	<JIRA.12584081.1441412121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584081.1441412121000.19939.1441894380194@Atlassian.JIRA>


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

Mario Fusco reassigned DROOLS-904:
----------------------------------

    Assignee: Mario Fusco  (was: Davide Sottara)


> Trait proxy classes are not restored on persistent session deserialization
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-904
>                 URL: https://issues.jboss.org/browse/DROOLS-904
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.CR1, 6.3.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
> Deserializing a previously persisted session containing a proxy instance requires the 
> proxy class to be available to the KieBase's project class loader by the time the session is
> restored. However, a freshly recreated KieBase for the purpose of restoring a session will
> not have the proper classes loaded.
> Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:25:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 10:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.20001.1441895100245@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-840:
-----------------------------------------

I don't see how it is only applicable to 1 - if the resource does not have it's dependencies met then both capabiltiies it provides will also be unavailable.

> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:31:01 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Thu, 10 Sep 2015 10:31:01 -0400 (EDT)
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.1441895443275@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584582.1441895443000.20044.1441895461587@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5320:
--------------------------------------

             Summary: 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: Ond?ej Chaloupka
            Assignee: Tomasz Adamski
         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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 10:35:02 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 10 Sep 2015 10:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-904) Trait proxy classes are not
 restored on persistent session deserialization
In-Reply-To: <JIRA.12584081.1441412121000@Atlassian.JIRA>
References: <JIRA.12584081.1441412121000@Atlassian.JIRA>
	<JIRA.12584081.1441412121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584081.1441412121000.20153.1441895702034@Atlassian.JIRA>


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

Mario Fusco resolved DROOLS-904.
--------------------------------
    Fix Version/s: 6.3.0.Final
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/523ba84db

> Trait proxy classes are not restored on persistent session deserialization
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-904
>                 URL: https://issues.jboss.org/browse/DROOLS-904
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.CR1, 6.3.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 6.3.0.Final
>
>
> Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
> Deserializing a previously persisted session containing a proxy instance requires the 
> proxy class to be available to the KieBase's project class loader by the time the session is
> restored. However, a freshly recreated KieBase for the purpose of restoring a session will
> not have the proper classes loaded.
> Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 10:46:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 10:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.20263.1441896362369@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-840:
-----------------------------------------

So, before capabilities, if the resource installed a service A that depended on some external service Z, but it also installs a second service B, should it record that B depends on Z? After all, if Z isn't there, the whole thing is going to get rolled back, so B really does depend a Z.

I'm fine with an overloaded variant of this for the common case where the resource only has a single capability, assuming the wiring can be worked out. But if there's ambiguity, it should fail.

> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:01:02 2015
From: issues at jboss.org (Sarah Julia Kriesch (JIRA))
Date: Thu, 10 Sep 2015 11:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5291) Cache will be cleaned
 automatically with a restart
In-Reply-To: <JIRA.12584182.1441643058000@Atlassian.JIRA>
References: <JIRA.12584182.1441643058000@Atlassian.JIRA>
	<JIRA.12584182.1441643058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584182.1441643058000.20364.1441897262596@Atlassian.JIRA>


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

Sarah Julia Kriesch commented on WFLY-5291:
-------------------------------------------

Thanks for the hint!

We are using WildFly 8.2.0.Final and JBoss AS 7.1.3.Final.


> Cache will be cleaned automatically with a restart
> --------------------------------------------------
>
>                 Key: WFLY-5291
>                 URL: https://issues.jboss.org/browse/WFLY-5291
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>         Environment: for all WildFly Application Servers on every operating system
>            Reporter: Sarah Julia Kriesch
>            Assignee: Jason Greene
>            Priority: Minor
>
> We are using JBoss/ WildFly for our application and have the problem, that you have to shutdown WildFly for clearing the cache.
> A full cache is using a lot of performance. Our customers are not happy, if we would have to shutdown the server for cleanings additionally to application hotfixes.
> My idea:
> A new feature with cleaning the cache (/tmp and /work) automatically with the restart of the application server.  
> benefits:
> - better performance for the application server
> - applications are faster
> - lower technical problems with the application
> - lower work for the System Administrator
> - more place on the hard disk
> - customers are happy :-)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:04:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Thu, 10 Sep 2015 11:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393437@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.20538.1441897440852@Atlassian.JIRA>

Geoffrey De Smet created WFLY-5321:
--------------------------------------

             Summary: Deploying a war to wildfly should mention the localhost url including context root of that war in the log
                 Key: WFLY-5321
                 URL: https://issues.jboss.org/browse/WFLY-5321
             Project: WildFly
          Issue Type: Enhancement
            Reporter: Geoffrey De Smet
            Assignee: Jason Greene


Here what I see now in the log:

{code}
[2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
...
16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
[2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
[2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
{code}

But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
- http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
- http://localhost:8080/optaconf-webapp/
- http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:13:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Sep 2015 11:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.20633.1441897980686@Atlassian.JIRA>


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

Tomaz Cerar commented on WFLY-5321:
-----------------------------------

there is extra log message which you didn't include that tells you on what context it is listening.

something along the lines:

{noformat}
2015-08-17 15:56:43,231 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 10) WFLYUT0021: Registered web context: /optaconf
{noformat}

but that doesn't include full url itself.

> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5321
>                 URL: https://issues.jboss.org/browse/WFLY-5321
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:14:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Sep 2015 11:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.20648.1441898040810@Atlassian.JIRA>


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

Tomaz Cerar reassigned WFLY-5321:
---------------------------------

    Component/s: Web (Undertow)
       Priority: Minor  (was: Major)
       Assignee: Tomaz Cerar  (was: Jason Greene)


> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5321
>                 URL: https://issues.jboss.org/browse/WFLY-5321
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:34:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 11:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5316) Duplicate auth directories in
	Wildfly 10
In-Reply-To: <JIRA.12584467.1441825072000@Atlassian.JIRA>
References: <JIRA.12584467.1441825072000@Atlassian.JIRA>
	<JIRA.12584467.1441825072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584467.1441825072000.20714.1441899240237@Atlassian.JIRA>


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

Darran Lofthouse reassigned WFLY-5316:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Paul Gier)


> Duplicate auth directories in Wildfly 10
> ----------------------------------------
>
>                 Key: WFLY-5316
>                 URL: https://issues.jboss.org/browse/WFLY-5316
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System, Security
>            Reporter: Fernando Nasser
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> The Wildfly 10 build creates two "auth" directories, one under each config:
> WILDFLY_HOME/domain/tmp: auth
> WILDFLY_HOME/standalone/tmp: auth
> while in Wildfly 8 there was a single "auth" dir at top-level:
> WILDFLY_HOME/auth
> Apparently there is no changes to the code changing where the 'auth' directory is looked for so this may be an issue with the new build system (or was an issue with the old one, but that is not documented).  And as the code creates it if it does not exist this may have been unnoticed in either case.
> We need to get this sorted out asap so we make sure these directories (or directory) are (or is) created with the right permissions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:34:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 11:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5316) Duplicate auth directories in
	Wildfly 10
In-Reply-To: <JIRA.12584467.1441825072000@Atlassian.JIRA>
References: <JIRA.12584467.1441825072000@Atlassian.JIRA>
	<JIRA.12584467.1441825072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584467.1441825072000.20718.1441899240308@Atlassian.JIRA>


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

Darran Lofthouse updated WFLY-5316:
-----------------------------------
    Fix Version/s: 10.0.0.CR2


> Duplicate auth directories in Wildfly 10
> ----------------------------------------
>
>                 Key: WFLY-5316
>                 URL: https://issues.jboss.org/browse/WFLY-5316
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System, Security
>            Reporter: Fernando Nasser
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> The Wildfly 10 build creates two "auth" directories, one under each config:
> WILDFLY_HOME/domain/tmp: auth
> WILDFLY_HOME/standalone/tmp: auth
> while in Wildfly 8 there was a single "auth" dir at top-level:
> WILDFLY_HOME/auth
> Apparently there is no changes to the code changing where the 'auth' directory is looked for so this may be an issue with the new build system (or was an issue with the old one, but that is not documented).  And as the code creates it if it does not exist this may have been unnoticed in either case.
> We need to get this sorted out asap so we make sure these directories (or directory) are (or is) created with the right permissions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:39:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 10 Sep 2015 11:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.20734.1441899540256@Atlassian.JIRA>


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

Radoslav Husar resolved JBMETA-387.
-----------------------------------
    Resolution: Done


Fix version is 10.0.0.Beta4 but is not managed in this Jira. 

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 11:41:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 10 Sep 2015 11:41:00 -0400 (EDT)
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.20740.1441899660292@Atlassian.JIRA>


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

Amos Feng commented on WFLY-5224:
---------------------------------

Thanks [~maeste], it looks like we'd best to provide the custom operations such as "switch-to-process-id-uuid" and "switch-to-process-id-socket-bing" in WFLY-5141

> 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: Amos Feng
>            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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 12:17:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Sep 2015 12:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1060) When starting JBoss AS -b
 should work no matter how I start JBoss AS to bind it to the local
 interface
In-Reply-To: <JIRA.12469850.1341334879000@Atlassian.JIRA>
References: <JIRA.12469850.1341334879000@Atlassian.JIRA>
	<JIRA.12469850.1341334879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469850.1341334879000.20793.1441901820207@Atlassian.JIRA>


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

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

Marek Kopecky <mkopecky at redhat.com> changed the Status of [bug 1125025|https://bugzilla.redhat.com/show_bug.cgi?id=1125025] from ON_QA to ASSIGNED

> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1060
>                 URL: https://issues.jboss.org/browse/WFLY-1060
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>              Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address.  Instead it binds to localhost 127.0.0.1.  It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 12:39:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 10 Sep 2015 12:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-904) Trait proxy classes are not
 restored on persistent session deserialization
In-Reply-To: <JIRA.12584081.1441412121000@Atlassian.JIRA>
References: <JIRA.12584081.1441412121000@Atlassian.JIRA>
	<JIRA.12584081.1441412121000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584081.1441412121000.20888.1441903140141@Atlassian.JIRA>


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

Mario Fusco commented on DROOLS-904:
------------------------------------

Also this commit is necessary https://github.com/droolsjbpm/drools/commit/c1e310289

> Trait proxy classes are not restored on persistent session deserialization
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-904
>                 URL: https://issues.jboss.org/browse/DROOLS-904
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.CR1, 6.3.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 6.3.0.Final
>
>
> Trait proxy classes are created lazily at runtime when a trait is instantiated for the first time.
> Deserializing a previously persisted session containing a proxy instance requires the 
> proxy class to be available to the KieBase's project class loader by the time the session is
> restored. However, a freshly recreated KieBase for the purpose of restoring a session will
> not have the proper classes loaded.
> Note: to date, existing serialization tests reuse the same KieBase, thus not showing the issue.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 12:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 12:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-918) Allow embedded server
 logging to be overridden by properties
In-Reply-To: <JIRA.12582602.1440536271000@Atlassian.JIRA>
References: <JIRA.12582602.1440536271000@Atlassian.JIRA>
	<JIRA.12582602.1440536271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582602.1440536271000.20892.1441903140244@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-918:
------------------------------------
    Fix Version/s: 3.0.0.Beta1


I'm scheduling this for 3 as AFAIK it's not blocking anything required for 2 and it won't make 2.0.0.CR1.

> Allow embedded server logging to be overridden by properties
> ------------------------------------------------------------
>
>                 Key: WFCORE-918
>                 URL: https://issues.jboss.org/browse/WFCORE-918
>             Project: WildFly Core
>          Issue Type: Feature Request
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 3.0.0.Beta1
>
>
> For example:
> $ export JBOSS_HOME=/home/kwills/git/wildfly/build/target/wf/
> $ java -jar wildfly-10.0.0.CR1-SNAPSHOT/bin/client/jboss-cli-client.jar  -Djboss.server.base.dir=standalone1 -Djboss.server.log.dir=log
> [disconnected /] embed-server --std-out=echo
> This should log to $JBOSS_HOME/standalone1/log
> The properties available to override are: 
> jboss.server.base.dir defaults to jbossHome.getAbsolutePath() + File.separator + "standalone" ("domain" for domain servers).
> jboss.server.configuration.dir defaults to "configuration"
> jboss.server.log.dir defaults to log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:06:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 10 Sep 2015 14:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5322) Singleton deployment fails to
 automatically start on second node
In-Reply-To: <JIRA.12584623.1441908303000@Atlassian.JIRA>
References: <JIRA.12584623.1441908303000@Atlassian.JIRA>
	<JIRA.12584623.1441908303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584623.1441908303000.21124.1441908360605@Atlassian.JIRA>


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

Paul Ferraro moved JBEAP-1059 to WFLY-5322:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5322  (was: JBEAP-1059)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Clustering
                           (was: Clustering)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.Beta2
                           (was: 7.0.0.DR9)


> Singleton deployment fails to automatically start on second node
> ----------------------------------------------------------------
>
>                 Key: WFLY-5322
>                 URL: https://issues.jboss.org/browse/WFLY-5322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>         Attachments: singleton-deployment-descriptor.war
>
>
> After stopping the node on which the singleton deployment is active, the deployment will fail to automatically start on another node under these conditions:
> 1. Simple election policy with applied name preferences is used:
> {code:xml}
> <simple-election-policy>
>     <name-preferences>node1 node2</name-preferences>
> </simple-election-policy>
> {code} 
> 2. The server named "node2" starts first, so that singleton deployment is active for a while on this node, then server named "node1" is started.
> 3. The server named "node1" stops.
> Server "node1" stops without error, however server "node2" gets NPE during the automatic re-deployment. 
> The same issue occurs when trying with latest wildfly upstream/master bits. 
> Server logs:
> {code:title=Server 1 log}
> [mvinkler at localhost jboss-eap-7.0_1]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_1
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:24:51,402 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 15:24:51,667 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 15:24:51,718 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 15:24:52,542 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 16) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 15:24:52,574 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 21) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/data/content/bd/6880bc84b90171ef3d37078e2c222b47647c13/content
> 15:24:52,643 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 15:24:52,659 INFO  [org.xnio] (MSC service thread 1-7) XNIO version 3.4.0.Beta1
> 15:24:52,670 INFO  [org.xnio.nio] (MSC service thread 1-7) XNIO NIO Implementation Version 3.4.0.Beta1
> 15:24:52,694 INFO  [org.jboss.remoting] (MSC service thread 1-7) JBoss Remoting version 4.0.9.Final
> 15:24:52,791 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 15:24:52,795 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 15:24:52,799 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 15:24:52,812 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 15:24:52,817 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 15:24:52,823 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 15:24:52,826 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 15:24:52,834 INFO  [org.jboss.as.security] (MSC service thread 1-7) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 15:24:52,857 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 15:24:52,867 INFO  [org.jboss.as.connector] (MSC service thread 1-4) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 15:24:52,869 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 15:24:52,872 INFO  [org.jboss.as.naming] (MSC service thread 1-8) WFLYNAM0003: Starting Naming Service
> 15:24:52,873 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 15:24:52,874 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0018: Started Driver service with driver-name = h2
> 15:24:52,880 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:52,883 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:53,014 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_1/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 15:24:53,019 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server.
> 15:24:53,025 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting
> 15:24:53,083 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8009
> 15:24:53,083 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080
> 15:24:53,087 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 63) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 15:24:53,104 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 63) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 15:24:53,192 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 15:24:53,233 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "singleton-deployment-descriptor.war" (runtime-name: "singleton-deployment-descriptor.war")
> 15:24:53,241 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/deployments
> 15:24:53,350 INFO  [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 15:24:53,683 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:54,079 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000078: Starting JGroups channel server
> 15:24:54,088 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view for channel server: [node2|1] (2) [node2, node1]
> 15:24:54,091 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Channel server local address is node1, physical addresses are [127.0.0.1:55200]
> 15:24:54,140 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 15:24:54,315 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started default cache from server container
> 15:24:54,618 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 66) WFLYUT0021: Registered web context: /singleton-deployment-descriptor
> 15:24:54,657 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "singleton-deployment-descriptor.war" (runtime-name : "singleton-deployment-descriptor.war")
> 15:24:54,743 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:24:54,743 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 15:24:54,744 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 3611ms - Started 353 of 608 services (366 services are lazy, passive or on-demand)
> ^C15:25:04,667 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 15:25:04,680 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 21) WFLYUT0022: Unregistered web context: /singleton-deployment-descriptor
> 15:25:04,686 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host default-host stopping
> 15:25:04,686 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 23) MODCLUSTER000002: Initiating mod_cluster shutdown
> 15:25:04,687 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 15:25:04,689 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 15:25:04,698 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.2.1.Final
> 15:25:04,739 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 15:25:04,739 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment singleton-deployment-descriptor.war (runtime-name: singleton-deployment-descriptor.war) in 69ms
> 15:25:04,739 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow AJP listener ajp suspending
> 15:25:04,740 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 15:25:04,740 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 15:25:04,741 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> 15:25:04,744 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0003: Stopped default cache from server container
> 15:25:04,745 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 15:25:04,746 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 15:25:04,810 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 138ms
> {code}
> {code:title=Server 2 log}
> [mvinkler at localhost jboss-eap-7.0_2]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_2
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:24:45,219 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 15:24:45,386 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 15:24:45,435 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 15:24:46,261 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 15:24:46,296 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 23) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/data/content/bd/6880bc84b90171ef3d37078e2c222b47647c13/content
> 15:24:46,373 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 15:24:46,388 INFO  [org.xnio] (MSC service thread 1-6) XNIO version 3.4.0.Beta1
> 15:24:46,396 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.4.0.Beta1
> 15:24:46,431 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 15:24:46,431 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 15:24:46,456 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 15:24:46,458 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 15:24:46,531 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 15:24:46,535 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 15:24:46,545 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 15:24:46,576 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 15:24:46,579 INFO  [org.jboss.as.connector] (MSC service thread 1-3) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 15:24:46,580 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0018: Started Driver service with driver-name = h2
> 15:24:46,586 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 15:24:46,590 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 4.0.9.Final
> 15:24:46,599 INFO  [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service
> 15:24:46,602 INFO  [org.jboss.as.security] (MSC service thread 1-3) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 15:24:46,605 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-7) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 15:24:46,642 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:46,642 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:46,767 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_2/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 15:24:46,785 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server.
> 15:24:46,788 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0018: Host default-host starting
> 15:24:46,832 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8180
> 15:24:46,835 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8109
> 15:24:46,838 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 15:24:46,846 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 15:24:46,966 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 15:24:46,980 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-8) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/deployments
> 15:24:47,001 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "singleton-deployment-descriptor.war" (runtime-name: "singleton-deployment-descriptor.war")
> 15:24:47,128 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 15:24:47,436 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:50,836 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000078: Starting JGroups channel server
> 15:24:50,848 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000094: Received new cluster view for channel server: [node2|0] (1) [node2]
> 15:24:50,851 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000079: Channel server local address is node2, physical addresses are [127.0.0.1:55300]
> 15:24:50,854 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 15:24:50,967 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started default cache from server container
> 15:24:50,999 INFO  [org.wildfly.clustering.server] (ServerService Thread Pool -- 64) WFLYCLSV0003: node2 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:24:51,286 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 68) WFLYUT0021: Registered web context: /singleton-deployment-descriptor
> 15:24:51,326 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "singleton-deployment-descriptor.war" (runtime-name : "singleton-deployment-descriptor.war")
> 15:24:51,423 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:10090/management
> 15:24:51,423 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:10090
> 15:24:51,424 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 6404ms - Started 353 of 608 services (366 services are lazy, passive or on-demand)
> 15:24:53,753 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|1] (2) [node2, node1]
> 15:24:54,251 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=1, rebalanceId=1, currentCH=ReplicatedConsistentHash{ns = 60, owners = (1)[node2: 60]}, pendingCH=ReplicatedConsistentHash{ns = 60, owners = (2)[node2: 30, node1: 30]}, unionCH=null, actualMembers=[node2, node1]}
> 15:24:54,312 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000336: Finished cluster-wide rebalance for cache default, topology id = 1
> 15:24:54,347 INFO  [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:24:54,376 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 64) WFLYUT0022: Unregistered web context: /singleton-deployment-descriptor
> 15:24:54,393 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-4) HV000001: Hibernate Validator 5.2.1.Final
> 15:25:04,674 INFO  [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0003: node2 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:25:04,733 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: org.jboss.msc.service.StartException in service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "singleton-deployment-descriptor.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>         ... 5 more
> 15:25:04,735 ERROR [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0005: Failed to start jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service service: org.jboss.msc.service.StartException in service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "singleton-deployment-descriptor.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>         ... 5 more
> 15:25:04,807 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|2] (1) [node2]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:09:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-365) inconsistent usage of
 min/max-occurs in model description
In-Reply-To: <JIRA.12470576.1342507607000@Atlassian.JIRA>
References: <JIRA.12470576.1342507607000@Atlassian.JIRA>
	<JIRA.12470576.1342507607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470576.1342507607000.21135.1441908540408@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-365:
-----------------------------------------

The code now matches the specification in https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-DescriptionoftheManagementModel which differs from the poorly thought out spec in previous releases. The cardinality information is now part of the data for each resource definition (alongside description, attributes, operations, children, etc) and isn't part of the description of the "child-type".

> inconsistent usage of min/max-occurs in model description
> ---------------------------------------------------------
>
>                 Key: WFCORE-365
>                 URL: https://issues.jboss.org/browse/WFCORE-365
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR1
>
>         Attachments: patch.txt
>
>
> The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation.
> I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it.
> [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+Model



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:17:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:17:00 -0400 (EDT)
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.21160.1441909020118@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 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. The "jts" attribute in the transactions subsystem comes to mind.



> "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: 2.0.0.CR1
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:18:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:18:00 -0400 (EDT)
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.21162.1441909080053@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: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> "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: 2.0.0.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:22:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 10 Sep 2015 14:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3351) WildFly self-monitoring
 (history storage + REST API + web console plugin)
In-Reply-To: <JIRA.12540683.1399994205000@Atlassian.JIRA>
References: <JIRA.12540683.1399994205000@Atlassian.JIRA>
	<JIRA.12540683.1399994205000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540683.1399994205000.21166.1441909320264@Atlassian.JIRA>


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

James Perkins updated WFLY-3351:
--------------------------------
    Priority: Optional  (was: Major)


> WildFly self-monitoring (history storage + REST API + web console plugin)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3351
>                 URL: https://issues.jboss.org/browse/WFLY-3351
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: Ondrej Zizka
>            Assignee: James Perkins
>            Priority: Optional
>
> Would be nice if WildFly had it's optional own submodule which would monitor the AS, store the data, and allow it's retrieval later through REST API. Also, the console could have a plugin to read and display these data.
> This was discussed some time ago as one of requirements by different parties - JON, JBDS, end users.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:24:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-785) Improve capability related
	error messages
In-Reply-To: <JIRA.12576642.1435679852000@Atlassian.JIRA>
References: <JIRA.12576642.1435679852000@Atlassian.JIRA>
	<JIRA.12576642.1435679852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576642.1435679852000.21180.1441909440243@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-785:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Improve capability related error messages
> -----------------------------------------
>
>                 Key: WFCORE-785
>                 URL: https://issues.jboss.org/browse/WFCORE-785
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:25:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-785) Improve capability related
	error messages
In-Reply-To: <JIRA.12576642.1435679852000@Atlassian.JIRA>
References: <JIRA.12576642.1435679852000@Atlassian.JIRA>
	<JIRA.12576642.1435679852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576642.1435679852000.21198.1441909500209@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-785:
-----------------------------------------

This likely won't happen for 2.0 but I've bumped it to CR2 just in case. Nothing should be done on this for CR2 though unless it's really simple. Anything complicated means this needs to be deferred to 3.

> Improve capability related error messages
> -----------------------------------------
>
>                 Key: WFCORE-785
>                 URL: https://issues.jboss.org/browse/WFCORE-785
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:29:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.21207.1441909740084@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-972:
------------------------------------
    Fix Version/s: 3.0.0.Beta1
                       (was: 2.0.0.CR1)


> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 3.0.0.Beta1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:33:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-98) Remoting is using the wrong
	protocol names
In-Reply-To: <JIRA.12552191.1410790941000@Atlassian.JIRA>
References: <JIRA.12552191.1410790941000@Atlassian.JIRA>
	<JIRA.12552191.1410790941000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552191.1410790941000.21223.1441909980363@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-98:
----------------------------------------

Isn't this a duplicate of WFCORE-296?

> Remoting is using the wrong protocol names
> ------------------------------------------
>
>                 Key: WFCORE-98
>                 URL: https://issues.jboss.org/browse/WFCORE-98
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Remoting
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>
> The Remoting protocol names are presently:
> * remoting
> * http-remoting
> * https-remoting
> They should be:
> * remote
> * remote+http
> * remote+https
> respectively.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:34:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-296) Switch URI scheme from
 remoting:// http-remoting:// https-remoting:// to remote:// remote+http://
 and remote+https://
In-Reply-To: <JIRA.12542570.1401734598000@Atlassian.JIRA>
References: <JIRA.12542570.1401734598000@Atlassian.JIRA>
	<JIRA.12542570.1401734598000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542570.1401734598000.21231.1441910040394@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-296:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR1)


> Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-296
>                 URL: https://issues.jboss.org/browse/WFCORE-296
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI, Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha1
>
>
> From [~dmlloyd]
> {quote}
> When we have multi-layer protocol going on, the URI scheme we should use 
> is like this:
>    outer+middle+inner://
> {quote}
> Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> The existing schemes will be needed for backwards compatibility but somehow deprecated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:35:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 14:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in
	bin
In-Reply-To: <JIRA.12472505.1344994425000@Atlassian.JIRA>
References: <JIRA.12472505.1344994425000@Atlassian.JIRA>
	<JIRA.12472505.1344994425000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472505.1344994425000.21255.1441910100956@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-25:
-----------------------------------
    Issue Type: Feature Request  (was: Bug)


> Windows PowerShell scripts in bin
> ---------------------------------
>
>                 Key: WFCORE-25
>                 URL: https://issues.jboss.org/browse/WFCORE-25
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:40:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :read-resource and :read-children-resources is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395194@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21276.1441910400305@Atlassian.JIRA>

Jason Greene created WFCORE-977:
-----------------------------------

             Summary: Parameter completion for :read-resource and :read-children-resources is broken
                 Key: WFCORE-977
                 URL: https://issues.jboss.org/browse/WFCORE-977
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 2.0.0.Beta5
            Reporter: Brian Stansberry
            Assignee: Alexey Loubyansky
            Priority: Critical
             Fix For: 2.0.0.Beta6


When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:41:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :read-resource and :read-children-resources is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21282.1441910460213@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.Beta6)


> Parameter completion for :read-resource and :read-children-resources is broken
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:42:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :read-resource and :read-children-resources is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21296.1441910520684@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Affects Version/s: 2.0.0.Beta6
                           (was: 2.0.0.Beta5)


> Parameter completion for :read-resource and :read-children-resources is broken
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:42:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :read-resource and :read-children-resources is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21308.1441910520968@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Affects Version/s: 2.0.0.CR1
                           (was: 2.0.0.Beta6)


> Parameter completion for :read-resource and :read-children-resources is broken
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:43:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :read-resource and :read-children-resources is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21313.1441910580175@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly-core/pull/1021)


> Parameter completion for :read-resource and :read-children-resources is broken
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:44:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :read-attribute and :write-attribute is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21319.1441910640221@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Summary: Parameter completion for :read-attribute and :write-attribute is broken  (was: Parameter completion for :read-resource and :read-children-resources is broken)


> Parameter completion for :read-attribute and :write-attribute is broken
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:44:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :read-attribute and :write-attribute is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21324.1441910640303@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Description: When I try to use tab completion to add parameters to "write-attribute" , it does not suggest any params but instead just closes the parameter list.  (was: When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list.)


> Parameter completion for :read-attribute and :write-attribute is broken
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "write-attribute" , it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:45:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :write-attribute is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21329.1441910700174@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Summary: Parameter completion for  :write-attribute is broken  (was: Parameter completion for :read-attribute and :write-attribute is broken)


> Parameter completion for  :write-attribute is broken
> ----------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "write-attribute" , it does not suggest any params but instead just closes the parameter list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 14:46:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 10 Sep 2015 14:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-977) Parameter completion for
 :write-attribute is broken
In-Reply-To: <JIRA.12584625.1441910395000@Atlassian.JIRA>
References: <JIRA.12584625.1441910395000@Atlassian.JIRA>
	<JIRA.12584625.1441910395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584625.1441910395000.21334.1441910760247@Atlassian.JIRA>


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

Jason Greene updated WFCORE-977:
--------------------------------
    Description: 
When I try to use tab completion to add parameters to "write-attribute" , it does not suggest any param values but instead just closes the parameter list.

For example:

:write-attribute(name=n)

  was:When I try to use tab completion to add parameters to "write-attribute" , it does not suggest any params but instead just closes the parameter list.



> Parameter completion for  :write-attribute is broken
> ----------------------------------------------------
>
>                 Key: WFCORE-977
>                 URL: https://issues.jboss.org/browse/WFCORE-977
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> When I try to use tab completion to add parameters to "write-attribute" , it does not suggest any param values but instead just closes the parameter list.
> For example:
> :write-attribute(name=n)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 15:01:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 15:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.21401.1441911660179@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-756:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 15:49:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Sep 2015 15:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1060) When starting JBoss AS -b
 should work no matter how I start JBoss AS to bind it to the local
 interface
In-Reply-To: <JIRA.12469850.1341334879000@Atlassian.JIRA>
References: <JIRA.12469850.1341334879000@Atlassian.JIRA>
	<JIRA.12469850.1341334879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469850.1341334879000.21531.1441914540142@Atlassian.JIRA>


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

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

Andrea Hoffer <ahoffer at redhat.com> changed the Status of [bug 1125025|https://bugzilla.redhat.com/show_bug.cgi?id=1125025] from ASSIGNED to MODIFIED

> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1060
>                 URL: https://issues.jboss.org/browse/WFLY-1060
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>              Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address.  Instead it binds to localhost 127.0.0.1.  It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 16:32:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 10 Sep 2015 16:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5322) Singleton deployment fails to
 automatically start on second node
In-Reply-To: <JIRA.12584623.1441908303000@Atlassian.JIRA>
References: <JIRA.12584623.1441908303000@Atlassian.JIRA>
	<JIRA.12584623.1441908303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584623.1441908303000.21698.1441917120198@Atlassian.JIRA>


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

Paul Ferraro commented on WFLY-5322:
------------------------------------

The issue here is that the last phase of deployment (i.e. CLEANUP) removes attachments that are needed by previous deployment phases.  Since we only rollback phases as far as the FIRST_MODULE_USE phase, these attachments are never recreated, thus we get failures like above.

> Singleton deployment fails to automatically start on second node
> ----------------------------------------------------------------
>
>                 Key: WFLY-5322
>                 URL: https://issues.jboss.org/browse/WFLY-5322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>         Attachments: singleton-deployment-descriptor.war
>
>
> After stopping the node on which the singleton deployment is active, the deployment will fail to automatically start on another node under these conditions:
> 1. Simple election policy with applied name preferences is used:
> {code:xml}
> <simple-election-policy>
>     <name-preferences>node1 node2</name-preferences>
> </simple-election-policy>
> {code} 
> 2. The server named "node2" starts first, so that singleton deployment is active for a while on this node, then server named "node1" is started.
> 3. The server named "node1" stops.
> Server "node1" stops without error, however server "node2" gets NPE during the automatic re-deployment. 
> The same issue occurs when trying with latest wildfly upstream/master bits. 
> Server logs:
> {code:title=Server 1 log}
> [mvinkler at localhost jboss-eap-7.0_1]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_1
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:24:51,402 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 15:24:51,667 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 15:24:51,718 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 15:24:52,542 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 16) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 15:24:52,574 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 21) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/data/content/bd/6880bc84b90171ef3d37078e2c222b47647c13/content
> 15:24:52,643 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 15:24:52,659 INFO  [org.xnio] (MSC service thread 1-7) XNIO version 3.4.0.Beta1
> 15:24:52,670 INFO  [org.xnio.nio] (MSC service thread 1-7) XNIO NIO Implementation Version 3.4.0.Beta1
> 15:24:52,694 INFO  [org.jboss.remoting] (MSC service thread 1-7) JBoss Remoting version 4.0.9.Final
> 15:24:52,791 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 15:24:52,795 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 15:24:52,799 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 15:24:52,812 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 15:24:52,817 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 15:24:52,823 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 15:24:52,826 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 15:24:52,834 INFO  [org.jboss.as.security] (MSC service thread 1-7) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 15:24:52,857 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 15:24:52,867 INFO  [org.jboss.as.connector] (MSC service thread 1-4) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 15:24:52,869 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 15:24:52,872 INFO  [org.jboss.as.naming] (MSC service thread 1-8) WFLYNAM0003: Starting Naming Service
> 15:24:52,873 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 15:24:52,874 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0018: Started Driver service with driver-name = h2
> 15:24:52,880 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:52,883 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:53,014 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_1/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 15:24:53,019 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server.
> 15:24:53,025 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting
> 15:24:53,083 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8009
> 15:24:53,083 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080
> 15:24:53,087 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 63) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 15:24:53,104 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 63) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 15:24:53,192 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 15:24:53,233 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "singleton-deployment-descriptor.war" (runtime-name: "singleton-deployment-descriptor.war")
> 15:24:53,241 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/deployments
> 15:24:53,350 INFO  [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 15:24:53,683 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:54,079 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000078: Starting JGroups channel server
> 15:24:54,088 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view for channel server: [node2|1] (2) [node2, node1]
> 15:24:54,091 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Channel server local address is node1, physical addresses are [127.0.0.1:55200]
> 15:24:54,140 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 15:24:54,315 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started default cache from server container
> 15:24:54,618 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 66) WFLYUT0021: Registered web context: /singleton-deployment-descriptor
> 15:24:54,657 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "singleton-deployment-descriptor.war" (runtime-name : "singleton-deployment-descriptor.war")
> 15:24:54,743 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:24:54,743 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 15:24:54,744 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 3611ms - Started 353 of 608 services (366 services are lazy, passive or on-demand)
> ^C15:25:04,667 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 15:25:04,680 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 21) WFLYUT0022: Unregistered web context: /singleton-deployment-descriptor
> 15:25:04,686 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host default-host stopping
> 15:25:04,686 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 23) MODCLUSTER000002: Initiating mod_cluster shutdown
> 15:25:04,687 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 15:25:04,689 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 15:25:04,698 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.2.1.Final
> 15:25:04,739 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 15:25:04,739 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment singleton-deployment-descriptor.war (runtime-name: singleton-deployment-descriptor.war) in 69ms
> 15:25:04,739 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow AJP listener ajp suspending
> 15:25:04,740 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 15:25:04,740 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 15:25:04,741 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> 15:25:04,744 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0003: Stopped default cache from server container
> 15:25:04,745 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 15:25:04,746 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 15:25:04,810 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 138ms
> {code}
> {code:title=Server 2 log}
> [mvinkler at localhost jboss-eap-7.0_2]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_2
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:24:45,219 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 15:24:45,386 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 15:24:45,435 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 15:24:46,261 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 15:24:46,296 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 23) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/data/content/bd/6880bc84b90171ef3d37078e2c222b47647c13/content
> 15:24:46,373 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 15:24:46,388 INFO  [org.xnio] (MSC service thread 1-6) XNIO version 3.4.0.Beta1
> 15:24:46,396 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.4.0.Beta1
> 15:24:46,431 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 15:24:46,431 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 15:24:46,456 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 15:24:46,458 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 15:24:46,531 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 15:24:46,535 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 15:24:46,545 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 15:24:46,576 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 15:24:46,579 INFO  [org.jboss.as.connector] (MSC service thread 1-3) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 15:24:46,580 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0018: Started Driver service with driver-name = h2
> 15:24:46,586 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 15:24:46,590 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 4.0.9.Final
> 15:24:46,599 INFO  [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service
> 15:24:46,602 INFO  [org.jboss.as.security] (MSC service thread 1-3) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 15:24:46,605 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-7) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 15:24:46,642 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:46,642 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:46,767 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_2/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 15:24:46,785 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server.
> 15:24:46,788 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0018: Host default-host starting
> 15:24:46,832 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8180
> 15:24:46,835 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8109
> 15:24:46,838 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 15:24:46,846 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 15:24:46,966 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 15:24:46,980 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-8) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/deployments
> 15:24:47,001 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "singleton-deployment-descriptor.war" (runtime-name: "singleton-deployment-descriptor.war")
> 15:24:47,128 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 15:24:47,436 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:50,836 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000078: Starting JGroups channel server
> 15:24:50,848 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000094: Received new cluster view for channel server: [node2|0] (1) [node2]
> 15:24:50,851 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000079: Channel server local address is node2, physical addresses are [127.0.0.1:55300]
> 15:24:50,854 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 15:24:50,967 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started default cache from server container
> 15:24:50,999 INFO  [org.wildfly.clustering.server] (ServerService Thread Pool -- 64) WFLYCLSV0003: node2 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:24:51,286 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 68) WFLYUT0021: Registered web context: /singleton-deployment-descriptor
> 15:24:51,326 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "singleton-deployment-descriptor.war" (runtime-name : "singleton-deployment-descriptor.war")
> 15:24:51,423 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:10090/management
> 15:24:51,423 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:10090
> 15:24:51,424 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 6404ms - Started 353 of 608 services (366 services are lazy, passive or on-demand)
> 15:24:53,753 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|1] (2) [node2, node1]
> 15:24:54,251 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=1, rebalanceId=1, currentCH=ReplicatedConsistentHash{ns = 60, owners = (1)[node2: 60]}, pendingCH=ReplicatedConsistentHash{ns = 60, owners = (2)[node2: 30, node1: 30]}, unionCH=null, actualMembers=[node2, node1]}
> 15:24:54,312 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000336: Finished cluster-wide rebalance for cache default, topology id = 1
> 15:24:54,347 INFO  [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:24:54,376 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 64) WFLYUT0022: Unregistered web context: /singleton-deployment-descriptor
> 15:24:54,393 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-4) HV000001: Hibernate Validator 5.2.1.Final
> 15:25:04,674 INFO  [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0003: node2 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:25:04,733 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: org.jboss.msc.service.StartException in service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "singleton-deployment-descriptor.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>         ... 5 more
> 15:25:04,735 ERROR [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0005: Failed to start jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service service: org.jboss.msc.service.StartException in service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "singleton-deployment-descriptor.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>         ... 5 more
> 15:25:04,807 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|2] (1) [node2]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 16:37:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 10 Sep 2015 16:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-98) Remoting is using the wrong
	protocol names
In-Reply-To: <JIRA.12552191.1410790941000@Atlassian.JIRA>
References: <JIRA.12552191.1410790941000@Atlassian.JIRA>
	<JIRA.12552191.1410790941000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552191.1410790941000.21721.1441917420488@Atlassian.JIRA>


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

Darran Lofthouse resolved WFCORE-98.
------------------------------------
    Resolution: Duplicate Issue


> Remoting is using the wrong protocol names
> ------------------------------------------
>
>                 Key: WFCORE-98
>                 URL: https://issues.jboss.org/browse/WFCORE-98
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Remoting
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>
> The Remoting protocol names are presently:
> * remoting
> * http-remoting
> * https-remoting
> They should be:
> * remote
> * remote+http
> * remote+https
> respectively.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 17:44:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Sep 2015 17:44:00 -0400 (EDT)
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.21909.1441921440421@Atlassian.JIRA>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1243553|https://bugzilla.redhat.com/show_bug.cgi?id=1243553] from ASSIGNED to POST

> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 17:46:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 10 Sep 2015 17:46:00 -0400 (EDT)
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.21911.1441921560100@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-5314:
--------------------------------------

change log: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=10053&version=12328056

> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 18:02:01 2015
From: issues at jboss.org (Rich DiCroce (JIRA))
Date: Thu, 10 Sep 2015 18:02:01 -0400 (EDT)
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.21930.1441922521075@Atlassian.JIRA>


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

Rich DiCroce commented on WFLY-4695:
------------------------------------

Is there any documentation that explains how the infinispan-query modules would be re-added? I can't find any.

I wanted to add the necessary modules to WildFly 10.0.0.Beta2 and play with the new continuous query feature that was added in Infinispan 8. But the way the Infinispan project packages the modules seemingly makes it impossible for them to actually work. I used the infinispan-as-embedded-modules zip file, since that's what the Infinispan download page links to. I've tried putting the modules in $WFLY/modules and in $WFLY/modules/system/layers/base, but the result is the same both ways. In order to make the Infinispan classes visible to the deployment, I have to add the necessary modules (org.infinispan, org.infinispan.commons, and org.infinispan.query) as dependencies in jboss-deployment-structure.xml. The problem is that the zip contains modules with the "ispn-8.0" slot instead of the "main" slot. So,
* if I don't specify a slot for any of the modules, deployment fails with "Caused by: org.jboss.modules.ModuleNotFoundException: org.infinispan.query:main" as one would expect.
* if I specify ispn-8.0 for all of the modules, deployment fails with "Caused by: java.lang.IllegalArgumentException: Can not set org.infinispan.AdvancedCache field xxx to org.jboss.as.clustering.infinispan.DefaultCache", which makes sense because WildFly uses the main slot when it starts Infinispan (and there is no way to make it use a different slot, as far as I can tell).
* if I specify ispn-8.0 for just the query module and leave the others on the main slot, deployment fails with "Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "org/infinispan/Cache""

Am I missing something here? Or is the Infinispan project just not packaging these modules correctly? If it's an Infinispan problem, I'll go raise an issue in their tracker.

> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:03:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 10 Sep 2015 19:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5323) session-id-length setting is
 ignored in clustered configurations
In-Reply-To: <JIRA.12584633.1441926150000@Atlassian.JIRA>
References: <JIRA.12584633.1441926150000@Atlassian.JIRA>
	<JIRA.12584633.1441926150851@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584633.1441926150000.21976.1441926180148@Atlassian.JIRA>

Radoslav Husar created WFLY-5323:
------------------------------------

             Summary: session-id-length setting is ignored in clustered configurations 
                 Key: WFLY-5323
                 URL: https://issues.jboss.org/browse/WFLY-5323
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:03:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 10 Sep 2015 19:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5323) Undertow's session-id-length
 setting is ignored in clustered configurations
In-Reply-To: <JIRA.12584633.1441926150000@Atlassian.JIRA>
References: <JIRA.12584633.1441926150000@Atlassian.JIRA>
	<JIRA.12584633.1441926150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584633.1441926150000.21979.1441926180245@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-5323:
---------------------------------
    Summary: Undertow's session-id-length setting is ignored in clustered configurations   (was: session-id-length setting is ignored in clustered configurations )


> Undertow's session-id-length setting is ignored in clustered configurations 
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5323
>                 URL: https://issues.jboss.org/browse/WFLY-5323
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:05:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 10 Sep 2015 19:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5323) Undertow's session-id-length
 setting is ignored in clustered configurations
In-Reply-To: <JIRA.12584633.1441926150000@Atlassian.JIRA>
References: <JIRA.12584633.1441926150000@Atlassian.JIRA>
	<JIRA.12584633.1441926150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584633.1441926150000.21982.1441926300108@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-5323:
---------------------------------
    Priority: Critical  (was: Major)


> Undertow's session-id-length setting is ignored in clustered configurations 
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5323
>                 URL: https://issues.jboss.org/browse/WFLY-5323
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:29:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 10 Sep 2015 19:29:00 -0400 (EDT)
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.21988.1441927740133@Atlassian.JIRA>


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

Stuart Douglas reassigned WFLY-5309:
------------------------------------

    Component/s: JSF
                     (was: Web (Undertow))
       Assignee:     (was: Stuart Douglas)


> 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
>         Attachments: pom.xml, 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.21992.1441928400282@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-840:
------------------------------------
        Parent:     (was: WFCORE-803)
    Issue Type: Enhancement  (was: Sub-task)


> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:43:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-869) command line option to turn
 off CLI security prompts in non-interactive mode
In-Reply-To: <JIRA.12580481.1438858498000@Atlassian.JIRA>
References: <JIRA.12580481.1438858498000@Atlassian.JIRA>
	<JIRA.12580481.1438858498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580481.1438858498000.21998.1441928580204@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-869:
-----------------------------------------

What's going to happen with this issue now that the way non-interactive CLI interacts with aesh has been redone? Can it be resolved? 

> command line option to turn off CLI security prompts in non-interactive mode
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-869
>                 URL: https://issues.jboss.org/browse/WFCORE-869
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Bartosz Spyrko-?mietanko
>            Assignee: Alexey Loubyansky
>
> When the management interface is secured using a SSL certificate and the certificate is not trusted by the client, user is shown following dialog to accept the certificate:
> {{Accept certificate? [N]o, [T]emporarily, [P]ermenantly : }}
> The prompt is also shown in non-interactive mode (using --file or --command). If the CLI call is a part of an automated process, this can lead to the process being blocked waiting for user input that never happens.
> If the jboss-cli is executed in non-interactive mode and the SSL certificate is not trusted, process should immediately fail with appropriate message. Username/password authentication prompt already works in this way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 10 19:45:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-841) Patching module testsuite
	failure
In-Reply-To: <JIRA.12579359.1437766085000@Atlassian.JIRA>
References: <JIRA.12579359.1437766085000@Atlassian.JIRA>
	<JIRA.12579359.1437766085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579359.1437766085000.22002.1441928700943@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-841:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Patching module testsuite failure
> ---------------------------------
>
>                 Key: WFCORE-841
>                 URL: https://issues.jboss.org/browse/WFCORE-841
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Patching 
>         Environment: $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> OS X Yosemite 10.10.4
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.CR1
>
>
> When running the core build locally , the 'patching' module testsuite fails:
> {code}
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
> Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
> testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase)  Time elapsed: 0.044 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
> 	at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
> 	at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
> {code}
> If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order.
> Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround.
> The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-826) List-* operations should
 accept also objects as value
In-Reply-To: <JIRA.12578306.1437060543000@Atlassian.JIRA>
References: <JIRA.12578306.1437060543000@Atlassian.JIRA>
	<JIRA.12578306.1437060543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578306.1437060543000.22005.1441928701044@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-826:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> List-* operations should accept also objects as value
> -----------------------------------------------------
>
>                 Key: WFCORE-826
>                 URL: https://issues.jboss.org/browse/WFCORE-826
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> in case where list contains objects and not just simple types 
> list operations complain:
> example:
> {noformat}
> [standalone at localhost:9990 /] /subsystem=messaging-activemq/server=default:list-add(name=incoming-interceptors, value={name=foo,module=bar})
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0097: Wrong type for value. Expected [STRING] but was OBJECT",
>     "rolled-back" => true
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-646) Product to Project Schema
	and Model Sync
In-Reply-To: <JIRA.12568717.1429281526000@Atlassian.JIRA>
References: <JIRA.12568717.1429281526000@Atlassian.JIRA>
	<JIRA.12568717.1429281526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568717.1429281526000.22008.1441928701152@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-646:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Product to Project Schema and Model Sync
> ----------------------------------------
>
>                 Key: WFCORE-646
>                 URL: https://issues.jboss.org/browse/WFCORE-646
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR1
>
>
> Periodic sync of EAP schemas with WildFly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-603) Simplify working with
	complex attributes
In-Reply-To: <JIRA.12566094.1426595216000@Atlassian.JIRA>
References: <JIRA.12566094.1426595216000@Atlassian.JIRA>
	<JIRA.12566094.1426595216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566094.1426595216000.22011.1441928701213@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-603:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Simplify working with complex attributes
> ----------------------------------------
>
>                 Key: WFCORE-603
>                 URL: https://issues.jboss.org/browse/WFCORE-603
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> This is umbrella issue for all complex attributes related enhancements and simplifications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.22020.1441928701460@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-310:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR1
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-278) Revisit error message for an
 authentication failure.
In-Reply-To: <JIRA.12536929.1396443828000@Atlassian.JIRA>
References: <JIRA.12536929.1396443828000@Atlassian.JIRA>
	<JIRA.12536929.1396443828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536929.1396443828000.22023.1441928701538@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-278:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Revisit error message for an authentication failure.
> ----------------------------------------------------
>
>                 Key: WFCORE-278
>                 URL: https://issues.jboss.org/browse/WFCORE-278
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR1
>
>
> After authentication fails in the CLI the following error message is output: -
> {code}
> Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms
> {code}
> This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to
 domain-management module
In-Reply-To: <JIRA.12553769.1412093571000@Atlassian.JIRA>
References: <JIRA.12553769.1412093571000@Atlassian.JIRA>
	<JIRA.12553769.1412093571000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553769.1412093571000.22026.1441928701642@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-137:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Add Kerberos tests to domain-management module
> ----------------------------------------------
>
>                 Key: WFCORE-137
>                 URL: https://issues.jboss.org/browse/WFCORE-137
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-103) Add Full Kerberos Support
In-Reply-To: <JIRA.12467133.1337768128000@Atlassian.JIRA>
References: <JIRA.12467133.1337768128000@Atlassian.JIRA>
	<JIRA.12467133.1337768128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467133.1337768128000.22036.1441928702081@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-103:
------------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Add Full Kerberos Support
> -------------------------
>
>                 Key: WFCORE-103
>                 URL: https://issues.jboss.org/browse/WFCORE-103
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: management_security,
>             Fix For: 2.0.0.CR1
>
>
> There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 19:45:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 19:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in
	bin
In-Reply-To: <JIRA.12472505.1344994425000@Atlassian.JIRA>
References: <JIRA.12472505.1344994425000@Atlassian.JIRA>
	<JIRA.12472505.1344994425000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472505.1344994425000.22047.1441928702356@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-25:
-----------------------------------
    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.Beta7)


> Windows PowerShell scripts in bin
> ---------------------------------
>
>                 Key: WFCORE-25
>                 URL: https://issues.jboss.org/browse/WFCORE-25
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 21:07:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 21:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.22091.1441933620115@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-628:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 21:07:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 21:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.22094.1441933620827@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-909:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 21:08:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 21:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-785) Improve capability related
	error messages
In-Reply-To: <JIRA.12576642.1435679852000@Atlassian.JIRA>
References: <JIRA.12576642.1435679852000@Atlassian.JIRA>
	<JIRA.12576642.1435679852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576642.1435679852000.22097.1441933680751@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-785:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Improve capability related error messages
> -----------------------------------------
>
>                 Key: WFCORE-785
>                 URL: https://issues.jboss.org/browse/WFCORE-785
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 21:08:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 21:08:00 -0400 (EDT)
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.22099.1441933680889@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: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> "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: 2.0.0.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 10 21:58:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 10 Sep 2015 21:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-841) Patching module testsuite
	failure
In-Reply-To: <JIRA.12579359.1437766085000@Atlassian.JIRA>
References: <JIRA.12579359.1437766085000@Atlassian.JIRA>
	<JIRA.12579359.1437766085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579359.1437766085000.22129.1441936680242@Atlassian.JIRA>


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

Brian Stansberry resolved WFCORE-841.
-------------------------------------
    Fix Version/s:     (was: 2.0.0.CR1)
       Resolution: Out of Date


Doesn't fail any more for me.

> Patching module testsuite failure
> ---------------------------------
>
>                 Key: WFCORE-841
>                 URL: https://issues.jboss.org/browse/WFCORE-841
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Patching 
>         Environment: $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> OS X Yosemite 10.10.4
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>
> When running the core build locally , the 'patching' module testsuite fails:
> {code}
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
> Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
> testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase)  Time elapsed: 0.044 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
> 	at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
> 	at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
> {code}
> If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order.
> Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround.
> The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 00:55:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Sep 2015 00:55:01 -0400 (EDT)
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.22377.1441947301119@Atlassian.JIRA>


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

RH Bugzilla Integration updated WFLY-5234:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1257692
        Bugzilla Update: Perform


> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 01:45:00 2015
From: issues at jboss.org (Michael Reynolds (JIRA))
Date: Fri, 11 Sep 2015 01:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-912) Add ability to enable the
 audit log from the Command interface
In-Reply-To: <JIRA.12584640.1441950283000@Atlassian.JIRA>
References: <JIRA.12584640.1441950283000@Atlassian.JIRA>
	<JIRA.12584640.1441950283124@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584640.1441950283000.22434.1441950300144@Atlassian.JIRA>

Michael Reynolds created DROOLS-912:
---------------------------------------

             Summary: Add ability to enable the audit log from the Command interface
                 Key: DROOLS-912
                 URL: https://issues.jboss.org/browse/DROOLS-912
             Project: Drools
          Issue Type: Enhancement
          Components: core engine
            Reporter: Michael Reynolds
            Assignee: Mario Fusco
            Priority: Minor


Implement the ability to enable the audit log from the Command API in drools-core.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 01:47:00 2015
From: issues at jboss.org (Michael Reynolds (JIRA))
Date: Fri, 11 Sep 2015 01:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-912) Add ability to enable the
 audit log from the Command interface
In-Reply-To: <JIRA.12584640.1441950283000@Atlassian.JIRA>
References: <JIRA.12584640.1441950283000@Atlassian.JIRA>
	<JIRA.12584640.1441950283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584640.1441950283000.22437.1441950420084@Atlassian.JIRA>


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

Michael Reynolds commented on DROOLS-912:
-----------------------------------------

I have already implemented this on my fork, I would just like to add unit tests to verify the behavior but need some guidance where the unit tests should go.

> Add ability to enable the audit log from the Command interface
> --------------------------------------------------------------
>
>                 Key: DROOLS-912
>                 URL: https://issues.jboss.org/browse/DROOLS-912
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>            Reporter: Michael Reynolds
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Implement the ability to enable the audit log from the Command API in drools-core.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 02:49:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Fri, 11 Sep 2015 02:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5324) in-vm acceptor/connector has
 no default value for server-id
In-Reply-To: <JIRA.12584644.1441954085000@Atlassian.JIRA>
References: <JIRA.12584644.1441954085000@Atlassian.JIRA>
	<JIRA.12584644.1441954085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584644.1441954085000.22844.1441954140301@Atlassian.JIRA>


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

Miroslav Novak moved JBEAP-1062 to WFLY-5324:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5324  (was: JBEAP-1062)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: JMS
                           (was: JMS)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.Beta2
                           (was: 7.0.0.DR9)


> in-vm acceptor/connector has no default value for server-id
> -----------------------------------------------------------
>
>                 Key: WFLY-5324
>                 URL: https://issues.jboss.org/browse/WFLY-5324
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> in-vm acceptor/connector in EAP 6 has default value for server-id set to 0. But in EAP 7 no default value is set. This causes that adding in-vm acceptor/connector without server-id in CLI succeeds in EAP 6 but fails in EAP 7. We should sync default values between EAP 6 and EAP 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 02:49:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 11 Sep 2015 02:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5279) Maven Central versions don't
 match wildfly.org: each have a version that the other doesn't have
In-Reply-To: <JIRA.12584010.1441369579000@Atlassian.JIRA>
References: <JIRA.12584010.1441369579000@Atlassian.JIRA>
	<JIRA.12584010.1441369579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584010.1441369579000.22847.1441954140407@Atlassian.JIRA>


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

Geoffrey De Smet commented on WFLY-5279:
----------------------------------------

Nevermind, the error is on my side:
I didn't know that the bom jboss-javaee-7.0-with-tools was renamed to jboss-javaee-wildfly-7.0-with-tools. So the 9.0.1 bom does exist on Maven Central.

https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.wildfly.bom~jboss-javaee-7.0-wildfly-with-tools~~~~kw,versionexpand

Furthermore, it looks like this confusing versioning issue has been fixed in the 9.x and 10.x series.

> Maven Central versions don't match wildfly.org: each have a version that the other doesn't have
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5279
>                 URL: https://issues.jboss.org/browse/WFLY-5279
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>
> On Maven central [1], I can find version {{8.2.2.Final}} which doesn't exist on wildfly.org [2].
> On the other hand, on wildfly.org [2], I can find version {{9.0.1.Final}} which isn't on Maven Central [1].
> This makes testing our libraries for wildfly (with arquillian) very confusing.
> [1] http://search.maven.org/#search|gav|1|g%3A%22org.wildfly.bom%22%20AND%20a%3A%22jboss-javaee-7.0-with-tools%22
> [2] http://wildfly.org/downloads/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 03:34:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 11 Sep 2015 03:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.22969.1441956840206@Atlassian.JIRA>


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

Geoffrey De Smet commented on WFLY-5321:
----------------------------------------

That log line doesn't show up, not in a fresh install of 9.0.1.Final (downloaded again this morning), nor in 8.1.0.Final. In the wildfly admin console I can see the deployment listed as succeeded, but I again don't find any reference to the web context nor the localhost url, not even in the undertow component. Seeing as I can't guess it either, I think the http service isn't actually there - but it would be nice to somehow confirm this.

Note: this issue is NOT about whatever is causing my http service to be not available (I must have made a mistake somewhere), instead it's about me not having enough feedback from wildfly to determine what's going on: it says it's deployed, it's a war with html files, but I can't find it. It should it say where it is or why it's failed.
Especially because deploying a war is a typical first user action, the error message experience is important to improve adoption.

> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5321
>                 URL: https://issues.jboss.org/browse/WFLY-5321
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 03:34:01 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 11 Sep 2015 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.22972.1441956841918@Atlassian.JIRA>


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

Geoffrey De Smet edited comment on WFLY-5321 at 9/11/15 3:33 AM:
-----------------------------------------------------------------

That log line doesn't show up, not in a fresh install of 9.0.1.Final (downloaded again this morning), nor in 8.1.0.Final. In the wildfly admin console I can see the deployment listed as succeeded, but I again don't find any reference to the web context nor the localhost url, not even in the undertow component. Seeing as I can't guess it either, I think the http service isn't actually there - but it would be nice to somehow confirm this.

Note: this issue is NOT about whatever is causing my http service to be not available (I must have made a mistake somewhere), instead it's about me not having enough feedback from wildfly 9 to determine what's going on: it says it's deployed, it's a war with html files, but I can't find it. It should it say where it is or why it's failed.
Especially because deploying a war is a typical first user action, the error message experience is important to improve adoption.


was (Author: ge0ffrey):
That log line doesn't show up, not in a fresh install of 9.0.1.Final (downloaded again this morning), nor in 8.1.0.Final. In the wildfly admin console I can see the deployment listed as succeeded, but I again don't find any reference to the web context nor the localhost url, not even in the undertow component. Seeing as I can't guess it either, I think the http service isn't actually there - but it would be nice to somehow confirm this.

Note: this issue is NOT about whatever is causing my http service to be not available (I must have made a mistake somewhere), instead it's about me not having enough feedback from wildfly to determine what's going on: it says it's deployed, it's a war with html files, but I can't find it. It should it say where it is or why it's failed.
Especially because deploying a war is a typical first user action, the error message experience is important to improve adoption.

> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5321
>                 URL: https://issues.jboss.org/browse/WFLY-5321
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 03:34:02 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 11 Sep 2015 03:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.22975.1441956842034@Atlassian.JIRA>


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

Geoffrey De Smet edited comment on WFLY-5321 at 9/11/15 3:33 AM:
-----------------------------------------------------------------

That log line doesn't show up, not in a fresh install of 9.0.1.Final (downloaded again this morning), nor in 8.1.0.Final. In the wildfly admin console I can see the deployment listed as succeeded, but I again don't find any reference to the web context nor the localhost url, not even in the undertow component. Seeing as I can't guess it either, I think the http service isn't actually there - but it would be nice to somehow confirm this.

Note: this issue is NOT about whatever is causing my http service to be not available (I must have made a mistake somewhere), instead it's about me not having enough feedback from wildfly 9 to determine what's going on: it says it's deployed, it's a war with html files, but I can't find the http service. It should it say where it is or why it's failed.
Especially because deploying a war is a typical first user action, the error message experience is important to improve adoption.


was (Author: ge0ffrey):
That log line doesn't show up, not in a fresh install of 9.0.1.Final (downloaded again this morning), nor in 8.1.0.Final. In the wildfly admin console I can see the deployment listed as succeeded, but I again don't find any reference to the web context nor the localhost url, not even in the undertow component. Seeing as I can't guess it either, I think the http service isn't actually there - but it would be nice to somehow confirm this.

Note: this issue is NOT about whatever is causing my http service to be not available (I must have made a mistake somewhere), instead it's about me not having enough feedback from wildfly 9 to determine what's going on: it says it's deployed, it's a war with html files, but I can't find it. It should it say where it is or why it's failed.
Especially because deploying a war is a typical first user action, the error message experience is important to improve adoption.

> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5321
>                 URL: https://issues.jboss.org/browse/WFLY-5321
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 04:06:00 2015
From: issues at jboss.org (Tristan Tarrant (JIRA))
Date: Fri, 11 Sep 2015 04:06:00 -0400 (EDT)
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.23050.1441958760289@Atlassian.JIRA>


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

Tristan Tarrant commented on WFLY-4695:
---------------------------------------

This is neither an Infinispan issue or a WildFly issue. Since Infinispan is also used internally by WildFly for its clustering, replacing/changing it is dangerous. The integration modules provided by Infinispan are for "side-along" installation, and that is the reason for the dedicated slot. You cannot mix these modules with the ones in the WildFly's 'main' slot. The downside of this is that applications need to handle clustering/configuration/lifecycle on their own, instead of relying on the container subsystem. It is our intention to also provide a side-along subsystem to overcome this issue too.


> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 04:16:01 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 11 Sep 2015 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.23065.1441959361735@Atlassian.JIRA>


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

Geoffrey De Smet commented on WFLY-5321:
----------------------------------------

By only doing this change:
  https://github.com/ge0ffrey/optaconf/commit/fa9f20fe6495e2f59e327d81556505b3579415a1
I do get the log line:
{code}
  09:59:21,709 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 17) WFLYUT0021: Registered web context: /optaconf-webapp
{code}

But without that change, I don't get the log line (nor can I find my html's).
However I don't see how that change, which adds the `<finalname>` in the pom.xml and removes the jboss-web.xml file can fix it so undertow does expose it.
Note: I deploy from IntelliJ IDEA 14.1.4 (= latest version).


So it seems that wildfly has been stating correct info all the time: it did deploy, but undertow exposed nothing. Although I would expect an error message from undertow as to why it didn't expose it. Furthermore, the question is what's causing undertow not to expose it: 

- a bug in WildFly?
- a bug in IntelliJ?
- something wrong in those few lines that my github commit above changes? I can't see how it could be that.


> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5321
>                 URL: https://issues.jboss.org/browse/WFLY-5321
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 04:17:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 11 Sep 2015 04:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5321) Deploying a war to wildfly
 should mention the localhost url including context root of that war in the
 log
In-Reply-To: <JIRA.12584589.1441897393000@Atlassian.JIRA>
References: <JIRA.12584589.1441897393000@Atlassian.JIRA>
	<JIRA.12584589.1441897393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584589.1441897393000.23071.1441959420369@Atlassian.JIRA>


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

Geoffrey De Smet edited comment on WFLY-5321 at 9/11/15 4:16 AM:
-----------------------------------------------------------------

After only doing this change:
  https://github.com/ge0ffrey/optaconf/commit/fa9f20fe6495e2f59e327d81556505b3579415a1
I do get the log line:
{code}
  09:59:21,709 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 17) WFLYUT0021: Registered web context: /optaconf-webapp
{code}
But without that change, I don't get the log line (nor can I find my html's).

I don't see how that change, which adds the `<finalname>` in the pom.xml and removes the jboss-web.xml file can fix it so undertow does expose it. I can only see how it could affect the url, but not how it could disable exposure alltogether.
Note: I deploy from IntelliJ IDEA 14.1.4 (= latest version).


So it seems that wildfly has been stating correct info all the time: it did deploy, but undertow exposed nothing. Although I would expect an error message from undertow as to why it didn't expose it. Furthermore, the question is what's causing undertow not to expose it: 

- a bug in WildFly?
- a bug in IntelliJ?
- something wrong in those few lines that my github commit above changes? I can't see how it could be that.



was (Author: ge0ffrey):
By only doing this change:
  https://github.com/ge0ffrey/optaconf/commit/fa9f20fe6495e2f59e327d81556505b3579415a1
I do get the log line:
{code}
  09:59:21,709 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 17) WFLYUT0021: Registered web context: /optaconf-webapp
{code}

But without that change, I don't get the log line (nor can I find my html's).
However I don't see how that change, which adds the `<finalname>` in the pom.xml and removes the jboss-web.xml file can fix it so undertow does expose it.
Note: I deploy from IntelliJ IDEA 14.1.4 (= latest version).


So it seems that wildfly has been stating correct info all the time: it did deploy, but undertow exposed nothing. Although I would expect an error message from undertow as to why it didn't expose it. Furthermore, the question is what's causing undertow not to expose it: 

- a bug in WildFly?
- a bug in IntelliJ?
- something wrong in those few lines that my github commit above changes? I can't see how it could be that.


> Deploying a war to wildfly should mention the localhost url including context root of that war in the log
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5321
>                 URL: https://issues.jboss.org/browse/WFLY-5321
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Geoffrey De Smet
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> Here what I see now in the log:
> {code}
> [2015-09-10 04:56:44,211] Artifact optaconf-webapp:war exploded: Artifact is being deployed, please wait...
> 16:56:44,235 INFO  [org.jboss.weld.deployer] (MSC service thread 1-9) JBAS016009: Stopping weld service for deployment optaconf-webapp-0.1.0-SNAPSHOT
> 16:56:44,244 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment optaconf-webapp-0.1.0-SNAPSHOT (runtime-name: optaconf-webapp-0.1.0-SNAPSHOT) in 15ms
> 16:56:44,255 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> 16:56:44,322 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name: "optaconf-webapp-0.1.0-SNAPSHOT")
> ...
> 16:56:44,508 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "optaconf-webapp-0.1.0-SNAPSHOT" (runtime-name : "optaconf-webapp-0.1.0-SNAPSHOT")
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Artifact is deployed successfully
> [2015-09-10 04:56:44,519] Artifact optaconf-webapp:war exploded: Deploy took 308 milliseconds
> {code}
> But as a developer, it's very hard to figure out the url to test the app, especially if someone changed it recently. Note that in my case it could be any of these, depending on the state of the jboss-web.xml, war file name (potentially exploded), IDE configuration, etc:
> - http://localhost:8080/optaconf-webapp-0.1.0-SNAPSHOT/
> - http://localhost:8080/optaconf-webapp/
> - http://localhost:8080/optaconf/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 04:50:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 11 Sep 2015 04:50:00 -0400 (EDT)
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.23149.1441961400046@Atlassian.JIRA>


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

Jeff Mesnil commented on WFLY-4902:
-----------------------------------

PR has been merged and rejected as it was introducing too many regression in WildFly test suite

> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 05:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 11 Sep 2015 05:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-840) Improve API on
 AttributeDefinitions where a capability is referenced.
In-Reply-To: <JIRA.12579310.1437747390000@Atlassian.JIRA>
References: <JIRA.12579310.1437747390000@Atlassian.JIRA>
	<JIRA.12579310.1437747390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579310.1437747390000.23228.1441963140500@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-840:
-----------------------------------------

As the name of the capability and the return type of the service are two independent things I think we could have a case where one resource has two capabilities backed by one service.

However the most pressing case that I think most will encounter is the single resource, single capability, single service - and currently has the attribute definition also needing to duplicate specifying the capability of the resource.



> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-840
>                 URL: https://issues.jboss.org/browse/WFCORE-840
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 05:45:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Fri, 11 Sep 2015 05:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.23315.1441964700327@Atlassian.JIRA>


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

Tomas Hofman commented on WFCORE-931:
-------------------------------------

[~luck3y] I will take this in case you didn't start yet.

> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 05:45:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Fri, 11 Sep 2015 05:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.23321.1441964700513@Atlassian.JIRA>


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

Tomas Hofman reassigned WFCORE-931:
-----------------------------------

    Assignee: Tomas Hofman  (was: Ken Wills)


> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Tomas Hofman
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 06:05:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 11 Sep 2015 06:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5293) EJB3 method invocation
 statistics exposed incorrectly through JMX
In-Reply-To: <JIRA.12584218.1441707247000@Atlassian.JIRA>
References: <JIRA.12584218.1441707247000@Atlassian.JIRA>
	<JIRA.12584218.1441707247000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584218.1441707247000.23366.1441965900296@Atlassian.JIRA>


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

Kabir Khan commented on WFLY-5293:
----------------------------------

The JMX layer just wraps what is in the real model and translates that. Putting a breakpoint at https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ejb/async/AsyncMethodTestCase.java#L210 so that I have some ejbs deployed, I see the following from the CLI
{code}
[standalone at localhost:9990 /] /deployment=AsyncTestCase.jar/subsystem=ejb3:read-resource(recursive=true,include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "entity-bean" => undefined,
        "message-driven-bean" => undefined,
        "singleton-bean" => {
            "AsyncSingleton" => {
                "component-class-name" => "AsyncSingleton",
                "declared-roles" => [],
                "execution-time" => 0L,
                "invocations" => 0L,
                "methods" => {},
                "peak-concurrent-invocations" => 0L,
                "run-as-role" => undefined,
                "security-domain" => "other",
                "timers" => [],
                "wait-time" => 0L,
                "service" => undefined
            },
            "AsyncBeanSynchronizeSingleton" => {
                "component-class-name" => "AsyncBeanSynchronizeSingleton",
                "declared-roles" => [],
                "execution-time" => 0L,
                "invocations" => 0L,
                "methods" => {},
                "peak-concurrent-invocations" => 0L,
                "run-as-role" => undefined,
                "security-domain" => "other",
                "timers" => [],
                "wait-time" => 0L,
                "service" => undefined
            }
        },
        "stateful-session-bean" => {"AsyncStateful" => {
            "cache-size" => 2,
            "component-class-name" => "AsyncStateful",
            "declared-roles" => [],
            "execution-time" => 0L,
            "invocations" => 0L,
            "methods" => {},
            "passivated-count" => 0,
            "peak-concurrent-invocations" => 0L,
            "run-as-role" => undefined,
            "security-domain" => "other",
            "total-size" => 2,
            "wait-time" => 0L,
            "service" => undefined
        }},
        "stateless-session-bean" => {
            "AsyncBeanRemote" => {
                "component-class-name" => "AsyncBeanRemote",
                "declared-roles" => [],
                "execution-time" => 0L,
                "invocations" => 0L,
                "methods" => {},
                "peak-concurrent-invocations" => 0L,
                "pool-available-count" => undefined,
                "pool-create-count" => undefined,
                "pool-current-size" => undefined,
                "pool-max-size" => undefined,
                "pool-name" => undefined,
                "pool-remove-count" => undefined,
                "run-as-role" => undefined,
                "security-domain" => "other",
                "timers" => [],
                "wait-time" => 0L,
                "service" => undefined
            },
            "AsyncChildBean" => {
                "component-class-name" => "AsyncChildBean",
                "declared-roles" => [],
                "execution-time" => 0L,
                "invocations" => 0L,
                "methods" => {},
                "peak-concurrent-invocations" => 0L,
                "pool-available-count" => undefined,
                "pool-create-count" => undefined,
                "pool-current-size" => undefined,
                "pool-max-size" => undefined,
                "pool-name" => undefined,
                "pool-remove-count" => undefined,
                "run-as-role" => undefined,
                "security-domain" => "other",
                "timers" => [],
                "wait-time" => 0L,
                "service" => undefined
            },
            "AsyncBeanDescriptor" => {
                "component-class-name" => "AsyncBeanDescriptor",
                "declared-roles" => [],
                "execution-time" => 0L,
                "invocations" => 0L,
                "methods" => {},
                "peak-concurrent-invocations" => 0L,
                "pool-available-count" => undefined,
                "pool-create-count" => undefined,
                "pool-current-size" => undefined,
                "pool-max-size" => undefined,
                "pool-name" => undefined,
                "pool-remove-count" => undefined,
                "run-as-role" => undefined,
                "security-domain" => "other",
                "timers" => [],
                "wait-time" => 0L,
                "service" => undefined
            },
            "AsyncBean" => {
                "component-class-name" => "AsyncBean",
                "declared-roles" => [],
                "execution-time" => 0L,
                "invocations" => 0L,
                "methods" => {},
                "peak-concurrent-invocations" => 0L,
                "pool-available-count" => undefined,
                "pool-create-count" => undefined,
                "pool-current-size" => undefined,
                "pool-max-size" => undefined,
                "pool-name" => undefined,
                "pool-remove-count" => undefined,
                "run-as-role" => undefined,
                "security-domain" => "other",
                "timers" => [],
                "wait-time" => 0L,
                "service" => undefined
            }
        }
    }
}
{code}
I am not familiar with what should be returned, but I think it looks like the returned metrics are not populated. Can you please confirm, and I will reassign to someone who can fix this.

> EJB3 method invocation statistics exposed incorrectly through JMX
> -----------------------------------------------------------------
>
>                 Key: WFLY-5293
>                 URL: https://issues.jboss.org/browse/WFLY-5293
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 9.0.1.Final
>            Reporter: Arto Huusko
>            Assignee: Kabir Khan
>
> EJB3 method invocation statistics, that is the "methods" attribute in an EJB3 session JMX object is exposed as CompositeDataSupport object that has the expected keys ("execution-time", and so on), but
> - the values for the keys are always null
> - there is only a single CompositeDataSupport object even when the session has several methods
> - the method name is not available.
> Possibly the invocation statistics should be exposed as an array of CompositeDataSupport objects where one of the keys is the method name.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 06:50:08 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Fri, 11 Sep 2015 06:50:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.23625.1441968608529@Atlassian.JIRA>


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

Ken Wills commented on WFCORE-931:
----------------------------------

I'm just about to work all of these embedded issues together, so I'd rather keep it.

> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Tomas Hofman
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 07:11:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Fri, 11 Sep 2015 07:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.23653.1441969860416@Atlassian.JIRA>


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

Tomas Hofman reassigned WFCORE-931:
-----------------------------------

    Assignee: Ken Wills  (was: Tomas Hofman)


> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 07:11:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Fri, 11 Sep 2015 07:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.23660.1441969860842@Atlassian.JIRA>


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

Tomas Hofman commented on WFCORE-931:
-------------------------------------

OK, reassigning back to you.

> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 07:30:00 2015
From: issues at jboss.org (David virgil naranjo (JIRA))
Date: Fri, 11 Sep 2015 07:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-796) Native maven pom parser
 doesn't work under OSGi
In-Reply-To: <JIRA.12573129.1432818035000@Atlassian.JIRA>
References: <JIRA.12573129.1432818035000@Atlassian.JIRA>
	<JIRA.12573129.1432818035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573129.1432818035000.23720.1441971000567@Atlassian.JIRA>


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

David virgil naranjo commented on DROOLS-796:
---------------------------------------------

Not working:

https://gist.github.com/dvirgiln/1e24a1df3843f31cb90e

I took one switchyard quickstart that is a container example that contains inside a drools file. 

I changed the default behaviour to check every 6 seconds for updates. 

The behaviour of kie scanner is working for simple poms. We have an integration test that is testing the Rules Loading, but with complex poms it is not working.

> Native maven pom parser doesn't work under OSGi
> -----------------------------------------------
>
>                 Key: DROOLS-796
>                 URL: https://issues.jboss.org/browse/DROOLS-796
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>         Attachments: switchyard-example-rules-kie.zip
>
>
> The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases.
> In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo:
> https://gist.github.com/dvirgiln/e5c69afc7434367e04c1
> This is executed on EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 07:30:00 2015
From: issues at jboss.org (David virgil naranjo (JIRA))
Date: Fri, 11 Sep 2015 07:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-796) Native maven pom parser
 doesn't work under OSGi
In-Reply-To: <JIRA.12573129.1432818035000@Atlassian.JIRA>
References: <JIRA.12573129.1432818035000@Atlassian.JIRA>
	<JIRA.12573129.1432818035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573129.1432818035000.23724.1441971000675@Atlassian.JIRA>


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

David virgil naranjo reopened DROOLS-796:
-----------------------------------------


See my comment

> Native maven pom parser doesn't work under OSGi
> -----------------------------------------------
>
>                 Key: DROOLS-796
>                 URL: https://issues.jboss.org/browse/DROOLS-796
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>         Attachments: switchyard-example-rules-kie.zip
>
>
> The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases.
> In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo:
> https://gist.github.com/dvirgiln/e5c69afc7434367e04c1
> This is executed on EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 07:51:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 11 Sep 2015 07:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.23867.1441972260424@Atlassian.JIRA>


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

Paul Ferraro updated WFLY-5290:
-------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/8090)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 11 08:11:00 2015
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Fri, 11 Sep 2015 08:11:00 -0400 (EDT)
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.23923.1441973460396@Atlassian.JIRA>


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

Sanne Grinovero commented on WFLY-4695:
---------------------------------------

To complement [~NadirX]'s answer: since the Infinispan version used by WildFly *internally* is hard to replace, for example because it would require lots of clustering tests to be repeated, end user applications which  wish to use Infinispan's latest version should use it as a separate module.

The modules system will keep them strictly separated, and the modules provided by Infinispan are extensively tested for this scenario. The practical downside is indeed that you have to use the {{jboss-deployment-structure.xml}} or the manifest approach to have your application explicitly look for the {{ispn-8.0}} (or any version you'd like).

The good news is that you'll always be able to use the latest version of Infinispan in your apps, without having to replace core components of the application server.

So the infinispan-query (and some other extensions too) were removed from the internal dependencies as they are not being used by the clustering subsystem: you should use the better tested and maintained ones which are distributed by the Infinispan project.

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 08:12:00 2015
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Fri, 11 Sep 2015 08:12:00 -0400 (EDT)
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.23932.1441973520769@Atlassian.JIRA>


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

Sanne Grinovero edited comment on WFLY-4695 at 9/11/15 8:11 AM:
----------------------------------------------------------------

To complement [~NadirX]'s answer: since the Infinispan version used by WildFly *internally* is hard to replace, for example because it would require lots of clustering tests to be repeated, end user applications which  wish to use Infinispan's latest version should use it as a separate module.

The modules system will keep them strictly separated, and the modules provided by Infinispan are extensively tested for this scenario. The practical downside is indeed that you have to use the {{jboss-deployment-structure.xml}} or the manifest approach to have your application explicitly look for the {{ispn-8.0}} slot (or any version you'd like).

The good news is that you'll always be able to use the latest version of Infinispan in your apps, without having to replace core components of the application server.

So the infinispan-query (and some other extensions too) were removed from the internal dependencies as they are not being used by the clustering subsystem: you should use the better tested and maintained ones which are distributed by the Infinispan project.


was (Author: sannegrinovero):
To complement [~NadirX]'s answer: since the Infinispan version used by WildFly *internally* is hard to replace, for example because it would require lots of clustering tests to be repeated, end user applications which  wish to use Infinispan's latest version should use it as a separate module.

The modules system will keep them strictly separated, and the modules provided by Infinispan are extensively tested for this scenario. The practical downside is indeed that you have to use the {{jboss-deployment-structure.xml}} or the manifest approach to have your application explicitly look for the {{ispn-8.0}} (or any version you'd like).

The good news is that you'll always be able to use the latest version of Infinispan in your apps, without having to replace core components of the application server.

So the infinispan-query (and some other extensions too) were removed from the internal dependencies as they are not being used by the clustering subsystem: you should use the better tested and maintained ones which are distributed by the Infinispan project.

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 08:14:00 2015
From: issues at jboss.org (Arto Huusko (JIRA))
Date: Fri, 11 Sep 2015 08:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5293) EJB3 method invocation
 statistics exposed incorrectly through JMX
In-Reply-To: <JIRA.12584218.1441707247000@Atlassian.JIRA>
References: <JIRA.12584218.1441707247000@Atlassian.JIRA>
	<JIRA.12584218.1441707247000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584218.1441707247000.23948.1441973640482@Atlassian.JIRA>


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

Arto Huusko commented on WFLY-5293:
-----------------------------------

In your example either no invocations have been done, or EJB statistics gathering is not enabled, and therefore methods is empty.

I tested a case where the cli does report usable statistics in the methods element, and still the JMX attribute is useless as described.

So in case of the methods attribute the JMX translation does not work correctly.

> EJB3 method invocation statistics exposed incorrectly through JMX
> -----------------------------------------------------------------
>
>                 Key: WFLY-5293
>                 URL: https://issues.jboss.org/browse/WFLY-5293
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 9.0.1.Final
>            Reporter: Arto Huusko
>            Assignee: Kabir Khan
>
> EJB3 method invocation statistics, that is the "methods" attribute in an EJB3 session JMX object is exposed as CompositeDataSupport object that has the expected keys ("execution-time", and so on), but
> - the values for the keys are always null
> - there is only a single CompositeDataSupport object even when the session has several methods
> - the method name is not available.
> Possibly the invocation statistics should be exposed as an array of CompositeDataSupport objects where one of the keys is the method name.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 08:14:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Sep 2015 08:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5323) Undertow's session-id-length
 setting is ignored in clustered configurations
In-Reply-To: <JIRA.12584633.1441926150000@Atlassian.JIRA>
References: <JIRA.12584633.1441926150000@Atlassian.JIRA>
	<JIRA.12584633.1441926150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584633.1441926150000.23951.1441973640548@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-5323:
---------------------------------
    Fix Version/s: 10.0.0.CR1


> Undertow's session-id-length setting is ignored in clustered configurations 
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5323
>                 URL: https://issues.jboss.org/browse/WFLY-5323
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 08:15:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Sep 2015 08:15:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5323) Undertow's session-id-length
 setting is ignored in clustered configurations
In-Reply-To: <JIRA.12584633.1441926150000@Atlassian.JIRA>
References: <JIRA.12584633.1441926150000@Atlassian.JIRA>
	<JIRA.12584633.1441926150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584633.1441926150000.23958.1441973700433@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-5323:
---------------------------------
    Labels: clustering_performance  (was: )


> Undertow's session-id-length setting is ignored in clustered configurations 
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5323
>                 URL: https://issues.jboss.org/browse/WFLY-5323
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>              Labels: clustering_performance
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 08:27:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Sep 2015 08:27:00 -0400 (EDT)
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.23993.1441974420389@Atlassian.JIRA>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1243553|https://bugzilla.redhat.com/show_bug.cgi?id=1243553] from POST to MODIFIED

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 08:47:00 2015
From: issues at jboss.org (Wessel Pieterse (JIRA))
Date: Fri, 11 Sep 2015 08:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5325) When Making any JAXRS rest
 call NPE is being thrown in
 org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
In-Reply-To: <JIRA.12584677.1441975568000@Atlassian.JIRA>
References: <JIRA.12584677.1441975568000@Atlassian.JIRA>
	<JIRA.12584677.1441975568717@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584677.1441975568000.24062.1441975620195@Atlassian.JIRA>

Wessel Pieterse created WFLY-5325:
-------------------------------------

             Summary: When Making any JAXRS rest call NPE is being thrown in  org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
                 Key: WFLY-5325
                 URL: https://issues.jboss.org/browse/WFLY-5325
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 9.0.1.Final
            Reporter: Wessel Pieterse
            Assignee: Jason Greene


The follwing line in my CORSFilter :


{code:java}
chain.doFilter(request, response);
{code}


causes

{code:java}

wildfly_1      | 12:41:34,692 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-8) Unknown exception while executing POST /orders/214/pay/creditcard/payu: java.lang.NullPointerException
wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
wildfly_1      | 
wildfly_1      | 12:41:34,693 ERROR [com.unijunction.ordercloud.filter.CORSFilter] (default task-8) CORSFilter failed :: javax.servlet.ServletException: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.cleanup(AdviceFilter.java:196)
wildfly_1      | 	at org.apache.shiro.web.filter.authc.AuthenticatingFilter.cleanup(AuthenticatingFilter.java:155)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:148)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
wildfly_1      | Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
wildfly_1      | 	at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247)
wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)
wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
wildfly_1      | 	... 52 more
wildfly_1      | Caused by: java.lang.NullPointerException
wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
wildfly_1      | 	... 65 more
{code}





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 08:54:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 11 Sep 2015 08:54:00 -0400 (EDT)
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.1441976026765@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584683.1441976026000.24122.1441976040798@Atlassian.JIRA>

Paul Ferraro created WFLY-5326:
----------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 10:00:01 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 11 Sep 2015 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5327) Support simple cache
 configuration in Infinispan subsystem
In-Reply-To: <JIRA.12584703.1441979958000@Atlassian.JIRA>
References: <JIRA.12584703.1441979958000@Atlassian.JIRA>
	<JIRA.12584703.1441979958288@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584703.1441979958000.24392.1441980001353@Atlassian.JIRA>

Paul Ferraro created WFLY-5327:
----------------------------------

             Summary: Support simple cache configuration in Infinispan subsystem
                 Key: WFLY-5327
                 URL: https://issues.jboss.org/browse/WFLY-5327
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


Infinispan 8.0.1.Final includes a new simple cache, that is effectively a local cache without an interceptor stack, and thus without support for transactions, persistence, etc.

Unfortunately, the configuration of such a cache in Infinispan is sloppy.  A simple cache is configured by a single boolean attribute, which of course means that all kinds of invalid configuration combinations are possible.  Ideally, a simple cache configuration should only expose relevant configuration aspects.  I propose we create a new cache type like so:
{code:xml}
<simple-cache name="...">
   <eviction .../>
   <expiration .../>
</simple-cache>
{code}

The fact that this doesn't translate into a designated cache mode is irrelevant.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 10:20:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Sep 2015 10:20:00 -0400 (EDT)
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.24488.1441981200074@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-5326:
--------------------------------------

changelog https://issues.jboss.org/projects/ISPN/versions/12328068

> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 10:21:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Sep 2015 10:21:00 -0400 (EDT)
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.24492.1441981260117@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-5326:
---------------------------------
    Labels: clustering_performance  (was: )


> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 11:06:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Fri, 11 Sep 2015 11:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5328) After setting
 journal-min-files to 0 through CLI server is throwing expection when
 reloading
In-Reply-To: <JIRA.12584541.1441882508000@Atlassian.JIRA>
References: <JIRA.12584541.1441882508000@Atlassian.JIRA>
	<JIRA.12584541.1441882508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584541.1441882508000.24578.1441983960541@Atlassian.JIRA>


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

Heiko Braun moved HAL-840 to WFLY-5328:
---------------------------------------

        Project: WildFly  (was: HAL)
            Key: WFLY-5328  (was: HAL-840)
       Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Component/s: Domain Management
                     (was: Subsystem Configuration)


> After setting journal-min-files to 0 through CLI server is throwing expection when reloading
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5328
>                 URL: https://issues.jboss.org/browse/WFLY-5328
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: Running unsecured EAP 7.0.0 DR9
>            Reporter: Patrik Cyprian
>
> When you set messaging journal-min-files to zero {{/subsystem=messaging-activemq/server=default:write-attribute(name=journal-min-files,value=0)}} , then when server is throwing exepciton *java.lang.IllegalArgumentException: minFiles cannot be less than*. In description there is no restriction for the attribute.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 11:07:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Fri, 11 Sep 2015 11:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5328) After setting
 journal-min-files to 0 through CLI server is throwing expection when
 reloading
In-Reply-To: <JIRA.12584541.1441882508000@Atlassian.JIRA>
References: <JIRA.12584541.1441882508000@Atlassian.JIRA>
	<JIRA.12584541.1441882508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584541.1441882508000.24588.1441984020175@Atlassian.JIRA>


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

Heiko Braun reassigned WFLY-5328:
---------------------------------

    Assignee: Brian Stansberry


> After setting journal-min-files to 0 through CLI server is throwing expection when reloading
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5328
>                 URL: https://issues.jboss.org/browse/WFLY-5328
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: Running unsecured EAP 7.0.0 DR9
>            Reporter: Patrik Cyprian
>            Assignee: Brian Stansberry
>
> When you set messaging journal-min-files to zero {{/subsystem=messaging-activemq/server=default:write-attribute(name=journal-min-files,value=0)}} , then when server is throwing exepciton *java.lang.IllegalArgumentException: minFiles cannot be less than*. In description there is no restriction for the attribute.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 11:08:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Fri, 11 Sep 2015 11:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5328) After setting
 journal-min-files to 0 through CLI server is throwing expection when
 reloading
In-Reply-To: <JIRA.12584541.1441882508000@Atlassian.JIRA>
References: <JIRA.12584541.1441882508000@Atlassian.JIRA>
	<JIRA.12584541.1441882508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584541.1441882508000.24593.1441984080160@Atlassian.JIRA>


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

Heiko Braun reassigned WFLY-5328:
---------------------------------

    Assignee: Jeff Mesnil  (was: Brian Stansberry)


> After setting journal-min-files to 0 through CLI server is throwing expection when reloading
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5328
>                 URL: https://issues.jboss.org/browse/WFLY-5328
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: Running unsecured EAP 7.0.0 DR9
>            Reporter: Patrik Cyprian
>            Assignee: Jeff Mesnil
>
> When you set messaging journal-min-files to zero {{/subsystem=messaging-activemq/server=default:write-attribute(name=journal-min-files,value=0)}} , then when server is throwing exepciton *java.lang.IllegalArgumentException: minFiles cannot be less than*. In description there is no restriction for the attribute.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 11:11:01 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Fri, 11 Sep 2015 11:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-917) "Could not initialize class
 java.lang.StringCoding" on HP-UX
In-Reply-To: <JIRA.12578426.1437137212000@Atlassian.JIRA>
References: <JIRA.12578426.1437137212000@Atlassian.JIRA>
	<JIRA.12578426.1437137212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578426.1437137212000.24618.1441984261045@Atlassian.JIRA>


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

Marek Kopeck? commented on WFCORE-917:
--------------------------------------

This issue is valid also for JDK "1.8.0.02-hp-ux".

This issue occurs also during EAP AS TS execution on HPUX.

> "Could not initialize class java.lang.StringCoding" on HP-UX
> ------------------------------------------------------------
>
>                 Key: WFCORE-917
>                 URL: https://issues.jboss.org/browse/WFCORE-917
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Marek Kopeck?
>            Assignee: Jason Greene
>
> *Description of problem:*
> "NoClassDefFoundError: Could not initialize class java.lang.StringCoding" occurs on HP-UX in a non-interactive mode of CLI
> This is intermittent issue.
> This exception occurs even without running domain server.
> *How reproducible:*
> 2% on HP-UX
> *Steps to Reproduce:*
> # ./domain.sh \# optional step
> # {noformat}for (( i = 1; i <= 200 ; i++ )) ; do
> ./jboss-cli.sh -c command="/profile=test:add"
> ./jboss-cli.sh -c command="/profile=test:remove"
> done{noformat}
> *Actual results:*
> {noformat}
> Exception: java.lang.NullPointerException thrown from the UncaughtExceptionHandler in thread "Finalizer"
> Error occurred during initialization of VM
> java.lang.NoClassDefFoundError: Could not initialize class java.lang.StringCoding
>         at java.lang.String.<init>(String.java:534)
>         at java.lang.String.<init>(String.java:554)
>         at java.lang.System.initProperties(Native Method)
>         at java.lang.System.initializeSystemClass(System.java:1164)
> {noformat}
> *Expected results:*
> No errors



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 11 11:17:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 11 Sep 2015 11:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-978) Build unnecessarily creates
 domain/data dir
In-Reply-To: <JIRA.12584713.1441984603000@Atlassian.JIRA>
References: <JIRA.12584713.1441984603000@Atlassian.JIRA>
	<JIRA.12584713.1441984603082@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584713.1441984603000.24672.1441984620606@Atlassian.JIRA>

Brian Stansberry created WFCORE-978:
---------------------------------------

             Summary: Build unnecessarily creates domain/data dir
                 Key: WFCORE-978
                 URL: https://issues.jboss.org/browse/WFCORE-978
             Project: WildFly Core
          Issue Type: Bug
          Components: Server
    Affects Versions: 2.0.0.Beta7
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR2


The build has been creating a dir in the domain tree going all the way back to very early days when it wasn't clear there wouldn't be a "deployments" dir analogous to standalone/deployments:

https://github.com/wildfly/wildfly-core/commit/9d2b1ac81c29b629b0426836d4dbe743e016d73f

Since then the name of the dir has been tweaked twice as people tried to guess what the point of it was, leading via a kind of game of telephone to the build now creating domain/data/content, something completely different from any "deployments" dir used by a scanner.

We don't precreate standalone/data/content and shouldn't need to precreate domain/data/content.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 11:27:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 11 Sep 2015 11:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5328) After setting
 journal-min-files to 0 through CLI server is throwing expection when
 reloading
In-Reply-To: <JIRA.12584541.1441882508000@Atlassian.JIRA>
References: <JIRA.12584541.1441882508000@Atlassian.JIRA>
	<JIRA.12584541.1441882508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584541.1441882508000.24717.1441985220339@Atlassian.JIRA>


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

Brian Stansberry updated WFLY-5328:
-----------------------------------
    Component/s: JMS
                     (was: Domain Management)


> After setting journal-min-files to 0 through CLI server is throwing expection when reloading
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5328
>                 URL: https://issues.jboss.org/browse/WFLY-5328
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>         Environment: Running unsecured EAP 7.0.0 DR9
>            Reporter: Patrik Cyprian
>            Assignee: Jeff Mesnil
>
> When you set messaging journal-min-files to zero {{/subsystem=messaging-activemq/server=default:write-attribute(name=journal-min-files,value=0)}} , then when server is throwing exepciton *java.lang.IllegalArgumentException: minFiles cannot be less than*. In description there is no restriction for the attribute.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 12:18:00 2015
From: issues at jboss.org (Rich DiCroce (JIRA))
Date: Fri, 11 Sep 2015 12:18:00 -0400 (EDT)
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.24870.1441988280283@Atlassian.JIRA>


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

Rich DiCroce commented on WFLY-4695:
------------------------------------

Thanks for the replies. Tristan, how concrete are the plans for that side-along subsystem? Is there an open issue for it? What does the timeline look like?

The lack of that subsystem is a huge problem for my application. I don't really care about being able to use a different Infinispan version than what WildFly is using, but I very much care about integration with the application server. And the modules currently provided by the Infinispan project effectively make that impossible. Sure, I can run all of Infinispan inside my application. I can define the necessary thread pools through the EE subsystem and I can probably get hold of the appropriate TransactionManagerLookup implementation somehow. But I can't see any way around having a completely separate JGroups channel, because the Infinispan modules bundle their own version in a separate slot, which means I can't piggyback on the channel that WildFly is using for everything else. That in turn means that different components would have different opinions about the topology of the cluster, and that feels like a disaster waiting to happen.

Besides, if I have to do all of the integration myself, that kinda defeats the purpose of having an application server, don't you think? :)

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 12:28:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 11 Sep 2015 12:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-287) Provide ability to specify
 flexible role mappers on an identity
In-Reply-To: <JIRA.12584726.1441988868000@Atlassian.JIRA>
References: <JIRA.12584726.1441988868000@Atlassian.JIRA>
	<JIRA.12584726.1441988868523@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584726.1441988868000.24894.1441988880183@Atlassian.JIRA>

David Lloyd created ELY-287:
-------------------------------

             Summary: Provide ability to specify flexible role mappers on an identity
                 Key: ELY-287
                 URL: https://issues.jboss.org/browse/ELY-287
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: API / SPI
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.Alpha1


* Allow SecurityIdentity to carry an immutable map of names to role mappers.
* Allow SecurityIdentity to be queried for category roles (defaulting to the empty role set).
* Allow a new SecurityIdentity to be created from an original SecurityIdentity, with a new role mapper for a given category name, if the calling class has adequate permissions.
* Allow SecurityDomain to specify an initial default set of names to role mappers.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 12:35:00 2015
From: issues at jboss.org (Khary Mendez (JIRA))
Date: Fri, 11 Sep 2015 12:35:00 -0400 (EDT)
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.24898.1441989300132@Atlassian.JIRA>


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

Khary Mendez commented on WFLY-5263:
------------------------------------

I recently ran into this issue in EAP 6.4  Any chance this can/will be rolled into the next EAP patch?

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 13:09:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 11 Sep 2015 13:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-822) Remove the 'NET' project
 from JBoss Negotiation
In-Reply-To: <JIRA.12538506.1397730613000@Atlassian.JIRA>
References: <JIRA.12538506.1397730613000@Atlassian.JIRA>
	<JIRA.12538506.1397730613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538506.1397730613000.24955.1441991340224@Atlassian.JIRA>


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

Darran Lofthouse updated SECURITY-822:
--------------------------------------
    Fix Version/s: Negotiation_3_0_0_Final
                       (was: Negotiation_2_2_11)
                       (was: Negotiation_2_3_9_CR1)


> Remove the 'NET' project from JBoss Negotiation
> -----------------------------------------------
>
>                 Key: SECURITY-822
>                 URL: https://issues.jboss.org/browse/SECURITY-822
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_Final
>
>
> The net project is not used in AS 7, EAP 6 or WildFly so time to delete it.
> In WildFly 9 an alternative SASL based approach will be used for EJB invocations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 13:20:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 11 Sep 2015 13:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-822) Remove the 'NET' project
 from JBoss Negotiation
In-Reply-To: <JIRA.12538506.1397730613000@Atlassian.JIRA>
References: <JIRA.12538506.1397730613000@Atlassian.JIRA>
	<JIRA.12538506.1397730613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538506.1397730613000.24973.1441992000420@Atlassian.JIRA>


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

Darran Lofthouse resolved SECURITY-822.
---------------------------------------
    Resolution: Done


> Remove the 'NET' project from JBoss Negotiation
> -----------------------------------------------
>
>                 Key: SECURITY-822
>                 URL: https://issues.jboss.org/browse/SECURITY-822
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_Final
>
>
> The net project is not used in AS 7, EAP 6 or WildFly so time to delete it.
> In WildFly 9 an alternative SASL based approach will be used for EJB invocations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 13:20:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 11 Sep 2015 13:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-822) Remove the 'NET' project
 from JBoss Negotiation
In-Reply-To: <JIRA.12538506.1397730613000@Atlassian.JIRA>
References: <JIRA.12538506.1397730613000@Atlassian.JIRA>
	<JIRA.12538506.1397730613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538506.1397730613000.24977.1441992000491@Atlassian.JIRA>


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

Darran Lofthouse updated SECURITY-822:
--------------------------------------
    Fix Version/s: Negotiation_3_0_0_CR1
                       (was: Negotiation_3_0_0_Final)


> Remove the 'NET' project from JBoss Negotiation
> -----------------------------------------------
>
>                 Key: SECURITY-822
>                 URL: https://issues.jboss.org/browse/SECURITY-822
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_CR1
>
>
> The net project is not used in AS 7, EAP 6 or WildFly so time to delete it.
> In WildFly 9 an alternative SASL based approach will be used for EJB invocations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 13:41:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Fri, 11 Sep 2015 13:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242115@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.25028.1441993260340@Atlassian.JIRA>

Ken Wills created WFCORE-979:
--------------------------------

             Summary: ignore-unused-configuration default value change testsuite changes.
                 Key: WFCORE-979
                 URL: https://issues.jboss.org/browse/WFCORE-979
             Project: WildFly Core
          Issue Type: Enhancement
            Reporter: Ken Wills
            Assignee: Ken Wills


This is a continuation of WFCORE-310, covering testsuite changes, post CR1.

>From [~brian.stansberry]:

 testsuite/domain/src/test/resources/host-configs/host-minimal.xml:

> @@ -59,7 +59,7 @@
>  
>      <domain-controller>
>          <!-- Remote domain controller configuration with a host and port -->
> -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
My comment here is more of a note for probably post CR1 work.

This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.

For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.

ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 13:44:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Fri, 11 Sep 2015 13:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.25029.1441993440043@Atlassian.JIRA>


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

Ken Wills commented on WFCORE-979:
----------------------------------

See also: https://github.com/wildfly/wildfly-core/pull/1057

> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
>                 Key: WFCORE-979
>                 URL: https://issues.jboss.org/browse/WFCORE-979
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
>  testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >  
> >      <domain-controller>
> >          <!-- Remote domain controller configuration with a host and port -->
> > -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 17:52:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 11 Sep 2015 17:52:00 -0400 (EDT)
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.1442008263834@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584739.1442008263000.25287.1442008320125@Atlassian.JIRA>

Jason Greene created WFLY-5329:
----------------------------------

             Summary: 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 11 23:50:00 2015
From: issues at jboss.org (Michael Reynolds (JIRA))
Date: Fri, 11 Sep 2015 23:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-912) Add ability to enable the
 audit log from the Command interface
In-Reply-To: <JIRA.12584640.1441950283000@Atlassian.JIRA>
References: <JIRA.12584640.1441950283000@Atlassian.JIRA>
	<JIRA.12584640.1441950283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584640.1441950283000.25365.1442029800211@Atlassian.JIRA>


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

Michael Reynolds updated DROOLS-912:
------------------------------------
    Git Pull Request: https://github.com/droolsjbpm/drools/pull/497, https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/98


> Add ability to enable the audit log from the Command interface
> --------------------------------------------------------------
>
>                 Key: DROOLS-912
>                 URL: https://issues.jboss.org/browse/DROOLS-912
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>            Reporter: Michael Reynolds
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Implement the ability to enable the audit log from the Command API in drools-core.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 07:58:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 12 Sep 2015 07:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.25372.1442059080157@Atlassian.JIRA>


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

Jan Kalina commented on ELY-282:
--------------------------------

So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) name ????
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

*David, what should be "(mapped) name"? Authentication/authorization id of user?*

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 08:06:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 12 Sep 2015 08:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.25381.1442059560148@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-282 at 9/12/15 8:05 AM:
---------------------------------------------------------

So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) name ????
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

*David, what should be "(mapped) name"? Authorization id of user from NameCallback of sasl server?*


was (Author: honza889):
So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) name ????
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

*David, what should be "(mapped) name"? Authentication/authorization id of user?*

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 08:09:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 12 Sep 2015 08:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.25384.1442059740107@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-282 at 9/12/15 8:08 AM:
---------------------------------------------------------

So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) name ????
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

*David, what should be "(mapped) name"? User name from NameCallback of sasl server?*


was (Author: honza889):
So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) name ????
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

*David, what should be "(mapped) name"? Authorization id of user from NameCallback of sasl server?*

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 08:17:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Sat, 12 Sep 2015 08:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5317) Upgrade to
 jboss-el-api_3.0_spec 1.0.5.Final
In-Reply-To: <JIRA.12584471.1441827468000@Atlassian.JIRA>
References: <JIRA.12584471.1441827468000@Atlassian.JIRA>
	<JIRA.12584471.1441827468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584471.1441827468000.25387.1442060220143@Atlassian.JIRA>


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

Scott Marlow closed WFLY-5317.
------------------------------
    Resolution: Done


> Upgrade to jboss-el-api_3.0_spec 1.0.5.Final
> --------------------------------------------
>
>                 Key: WFLY-5317
>                 URL: https://issues.jboss.org/browse/WFLY-5317
>             Project: WildFly
>          Issue Type: Task
>          Components: Server
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 08:18:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Sat, 12 Sep 2015 08:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5312) component upgrade to
 Hibernate ORM 5.0.1.Final
In-Reply-To: <JIRA.12584438.1441813999000@Atlassian.JIRA>
References: <JIRA.12584438.1441813999000@Atlassian.JIRA>
	<JIRA.12584438.1441813999000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584438.1441813999000.25390.1442060280205@Atlassian.JIRA>


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

Scott Marlow closed WFLY-5312.
------------------------------
    Resolution: Done


> component upgrade to Hibernate ORM 5.0.1.Final
> ----------------------------------------------
>
>                 Key: WFLY-5312
>                 URL: https://issues.jboss.org/browse/WFLY-5312
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR1
>
>
> Change JPA2LCTestCase to sleep before the EntityManager is created, so the Hibernate session timestamp is different than what the ClassFileTransformerTestCase timestamp.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 09:45:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sat, 12 Sep 2015 09:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-62)
 PersistentResourceXMLDescription enancements
In-Reply-To: <JIRA.12549820.1408617014000@Atlassian.JIRA>
References: <JIRA.12549820.1408617014000@Atlassian.JIRA>
	<JIRA.12549820.1408617014000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549820.1408617014000.25393.1442065500228@Atlassian.JIRA>


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

Tomaz Cerar resolved WFCORE-62.
-------------------------------
    Fix Version/s: 2.0.0.Beta7
       Resolution: Done


> PersistentResourceXMLDescription enancements
> --------------------------------------------
>
>                 Key: WFCORE-62
>                 URL: https://issues.jboss.org/browse/WFCORE-62
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha4
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.Beta7
>
>
> PersistentResourceXMLDescription & PersistentResourceDefinition need to be updated to add support for
> - use arbitrary attribute for "name"
> - have custom ElementParser



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 09:47:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sat, 12 Sep 2015 09:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-159) PropertyNotFoundException when
 the property is a JDK8 defender method
In-Reply-To: <JIRA.12547773.1406643062000@Atlassian.JIRA>
References: <JIRA.12547773.1406643062000@Atlassian.JIRA>
	<JIRA.12547773.1406643062000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547773.1406643062000.25398.1442065620213@Atlassian.JIRA>


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

Tomaz Cerar reassigned JBEE-159:
--------------------------------

    Assignee: Scott Marlow  (was: Tomaz Cerar)


I think this should be fixed already, but needs to be verified in any case.

> PropertyNotFoundException when the property is a JDK8 defender method
> ---------------------------------------------------------------------
>
>                 Key: JBEE-159
>                 URL: https://issues.jboss.org/browse/JBEE-159
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Enhancement
>          Components: jboss-el-api
>    Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
>            Reporter: Rich DiCroce
>            Assignee: Scott Marlow
>            Priority: Minor
>              Labels: java8
>
> I have a class that implements an interface that uses Java 8's new defender methods feature. Some getters on the interface have default implementations, and the concrete classes don't override them.
> If I try to refer to one of these getters as a property like so:
> {code:xml}
> value="#{cc.filter.filter.valueChoices}"
> {code}
> Then I get this exception:
> {noformat}
> Caused by: javax.el.PropertyNotFoundException: The class 'com.lapis.jsf.framework.dao.search.DefaultEntityFilter' does not have the property 'valueChoices'.
> 	at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:731) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> 	at javax.el.BeanELResolver.getValue(BeanELResolver.java:351) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> 	at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.6-jbossorg-4.jar:]
> 	at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.6-jbossorg-4.jar:]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:140) [javax.el-3.0.0.jar:]
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:]
> 	at com.sun.el.parser.AstEmpty.getValue(AstEmpty.java:66) [javax.el-3.0.0.jar:]
> 	at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:]
> 	at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> 	at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:158) [jsf-impl-2.2.6-jbossorg-4.jar:]
> 	at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.6-jbossorg-4.jar:]
> 	... 68 more
> {noformat}
> Two workarounds exist. One: you can override the default method in a concrete class and have it just call the default super method. Two: you can call the getter using a method expression instead of a value expression.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 12:21:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Sat, 12 Sep 2015 12:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5322) Singleton deployment fails to
 automatically start on second node
In-Reply-To: <JIRA.12584623.1441908303000@Atlassian.JIRA>
References: <JIRA.12584623.1441908303000@Atlassian.JIRA>
	<JIRA.12584623.1441908303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584623.1441908303000.25406.1442074860356@Atlassian.JIRA>


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

Paul Ferraro commented on WFLY-5322:
------------------------------------

I was able to remove the need for singleton deployments to have to restart the DeploymentUnitPhaseService for the FIRST_MODULE_USE phase, which effectively solves the problem.

> Singleton deployment fails to automatically start on second node
> ----------------------------------------------------------------
>
>                 Key: WFLY-5322
>                 URL: https://issues.jboss.org/browse/WFLY-5322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>         Attachments: singleton-deployment-descriptor.war
>
>
> After stopping the node on which the singleton deployment is active, the deployment will fail to automatically start on another node under these conditions:
> 1. Simple election policy with applied name preferences is used:
> {code:xml}
> <simple-election-policy>
>     <name-preferences>node1 node2</name-preferences>
> </simple-election-policy>
> {code} 
> 2. The server named "node2" starts first, so that singleton deployment is active for a while on this node, then server named "node1" is started.
> 3. The server named "node1" stops.
> Server "node1" stops without error, however server "node2" gets NPE during the automatic re-deployment. 
> The same issue occurs when trying with latest wildfly upstream/master bits. 
> Server logs:
> {code:title=Server 1 log}
> [mvinkler at localhost jboss-eap-7.0_1]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_1
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:24:51,402 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 15:24:51,667 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 15:24:51,718 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 15:24:52,542 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 16) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 15:24:52,574 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 21) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/data/content/bd/6880bc84b90171ef3d37078e2c222b47647c13/content
> 15:24:52,643 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 15:24:52,659 INFO  [org.xnio] (MSC service thread 1-7) XNIO version 3.4.0.Beta1
> 15:24:52,670 INFO  [org.xnio.nio] (MSC service thread 1-7) XNIO NIO Implementation Version 3.4.0.Beta1
> 15:24:52,694 INFO  [org.jboss.remoting] (MSC service thread 1-7) JBoss Remoting version 4.0.9.Final
> 15:24:52,791 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 15:24:52,795 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 15:24:52,799 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 15:24:52,812 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 15:24:52,817 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 15:24:52,823 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 15:24:52,826 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 15:24:52,834 INFO  [org.jboss.as.security] (MSC service thread 1-7) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 15:24:52,857 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 15:24:52,867 INFO  [org.jboss.as.connector] (MSC service thread 1-4) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 15:24:52,869 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 15:24:52,872 INFO  [org.jboss.as.naming] (MSC service thread 1-8) WFLYNAM0003: Starting Naming Service
> 15:24:52,873 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 15:24:52,874 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0018: Started Driver service with driver-name = h2
> 15:24:52,880 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:52,883 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:53,014 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_1/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 15:24:53,019 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server.
> 15:24:53,025 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting
> 15:24:53,083 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8009
> 15:24:53,083 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080
> 15:24:53,087 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 63) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 15:24:53,104 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 63) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 15:24:53,192 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 15:24:53,233 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "singleton-deployment-descriptor.war" (runtime-name: "singleton-deployment-descriptor.war")
> 15:24:53,241 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/deployments
> 15:24:53,350 INFO  [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 15:24:53,683 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:53,684 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-6) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:54,079 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000078: Starting JGroups channel server
> 15:24:54,088 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view for channel server: [node2|1] (2) [node2, node1]
> 15:24:54,091 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Channel server local address is node1, physical addresses are [127.0.0.1:55200]
> 15:24:54,140 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 15:24:54,315 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started default cache from server container
> 15:24:54,618 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 66) WFLYUT0021: Registered web context: /singleton-deployment-descriptor
> 15:24:54,657 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "singleton-deployment-descriptor.war" (runtime-name : "singleton-deployment-descriptor.war")
> 15:24:54,743 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:24:54,743 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 15:24:54,744 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 3611ms - Started 353 of 608 services (366 services are lazy, passive or on-demand)
> ^C15:25:04,667 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 15:25:04,680 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 21) WFLYUT0022: Unregistered web context: /singleton-deployment-descriptor
> 15:25:04,686 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host default-host stopping
> 15:25:04,686 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 23) MODCLUSTER000002: Initiating mod_cluster shutdown
> 15:25:04,687 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 15:25:04,689 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 15:25:04,698 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.2.1.Final
> 15:25:04,739 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 15:25:04,739 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment singleton-deployment-descriptor.war (runtime-name: singleton-deployment-descriptor.war) in 69ms
> 15:25:04,739 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow AJP listener ajp suspending
> 15:25:04,740 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 15:25:04,740 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 15:25:04,741 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> 15:25:04,744 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0003: Stopped default cache from server container
> 15:25:04,745 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 15:25:04,746 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 15:25:04,810 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 138ms
> {code}
> {code:title=Server 2 log}
> [mvinkler at localhost jboss-eap-7.0_2]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_2
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:24:45,219 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 15:24:45,386 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 15:24:45,435 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 15:24:46,261 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 25) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 15:24:46,296 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 23) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/data/content/bd/6880bc84b90171ef3d37078e2c222b47647c13/content
> 15:24:46,373 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 15:24:46,388 INFO  [org.xnio] (MSC service thread 1-6) XNIO version 3.4.0.Beta1
> 15:24:46,396 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.4.0.Beta1
> 15:24:46,431 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 15:24:46,431 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 15:24:46,456 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 15:24:46,458 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 15:24:46,531 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 15:24:46,535 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 15:24:46,545 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 15:24:46,576 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 15:24:46,579 INFO  [org.jboss.as.connector] (MSC service thread 1-3) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 15:24:46,580 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0018: Started Driver service with driver-name = h2
> 15:24:46,586 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 15:24:46,590 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 4.0.9.Final
> 15:24:46,599 INFO  [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service
> 15:24:46,602 INFO  [org.jboss.as.security] (MSC service thread 1-3) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 15:24:46,605 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-7) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 15:24:46,642 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:46,642 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 15:24:46,767 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_2/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 15:24:46,785 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0012: Started server default-server.
> 15:24:46,788 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0018: Host default-host starting
> 15:24:46,832 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8180
> 15:24:46,835 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8109
> 15:24:46,838 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 15:24:46,846 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 15:24:46,966 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 15:24:46,980 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-8) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/deployments
> 15:24:47,001 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "singleton-deployment-descriptor.war" (runtime-name: "singleton-deployment-descriptor.war")
> 15:24:47,128 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 15:24:47,436 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 15:24:47,437 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-2) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 15:24:50,836 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000078: Starting JGroups channel server
> 15:24:50,848 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000094: Received new cluster view for channel server: [node2|0] (1) [node2]
> 15:24:50,851 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000079: Channel server local address is node2, physical addresses are [127.0.0.1:55300]
> 15:24:50,854 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 15:24:50,967 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started default cache from server container
> 15:24:50,999 INFO  [org.wildfly.clustering.server] (ServerService Thread Pool -- 64) WFLYCLSV0003: node2 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:24:51,286 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 68) WFLYUT0021: Registered web context: /singleton-deployment-descriptor
> 15:24:51,326 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "singleton-deployment-descriptor.war" (runtime-name : "singleton-deployment-descriptor.war")
> 15:24:51,423 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:10090/management
> 15:24:51,423 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:10090
> 15:24:51,424 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started in 6404ms - Started 353 of 608 services (366 services are lazy, passive or on-demand)
> 15:24:53,753 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|1] (2) [node2, node1]
> 15:24:54,251 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=1, rebalanceId=1, currentCH=ReplicatedConsistentHash{ns = 60, owners = (1)[node2: 60]}, pendingCH=ReplicatedConsistentHash{ns = 60, owners = (2)[node2: 30, node1: 30]}, unionCH=null, actualMembers=[node2, node1]}
> 15:24:54,312 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000336: Finished cluster-wide rebalance for cache default, topology id = 1
> 15:24:54,347 INFO  [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:24:54,376 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 64) WFLYUT0022: Unregistered web context: /singleton-deployment-descriptor
> 15:24:54,393 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-4) HV000001: Hibernate Validator 5.2.1.Final
> 15:25:04,674 INFO  [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0003: node2 elected as the singleton provider of the jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE service
> 15:25:04,733 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: org.jboss.msc.service.StartException in service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "singleton-deployment-descriptor.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>         ... 5 more
> 15:25:04,735 ERROR [org.wildfly.clustering.server] (remote-thread--p2-t1) WFLYCLSV0005: Failed to start jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service service: org.jboss.msc.service.StartException in service jboss.deployment.unit."singleton-deployment-descriptor.war".FIRST_MODULE_USE.service: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "singleton-deployment-descriptor.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>         ... 5 more
> 15:25:04,807 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|2] (1) [node2]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 12 12:41:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sat, 12 Sep 2015 12:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.25410.1442076060230@Atlassian.JIRA>


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

David Lloyd commented on ELY-282:
---------------------------------

It is the authentication name, after all rewrites have been applied by the security domain and security realm.  In other words, the same name used to establish a realm identity.

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 13 09:13:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 13 Sep 2015 09:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.25426.1442149980211@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-282 at 9/13/15 9:12 AM:
---------------------------------------------------------

So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) user name
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

-David, what should be "(mapped) name"? User name from NameCallback of sasl server?-


was (Author: honza889):
So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) name ????
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

*David, what should be "(mapped) name"? User name from NameCallback of sasl server?*

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 13 12:16:02 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 13 Sep 2015 12:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-858) NoSuchMethodError on JIT
 Compilation of non-primitive comparison
In-Reply-To: <JIRA.12579278.1437730819000@Atlassian.JIRA>
References: <JIRA.12579278.1437730819000@Atlassian.JIRA>
	<JIRA.12579278.1437730819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579278.1437730819000.25433.1442160962013@Atlassian.JIRA>


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

RH Bugzilla Integration updated DROOLS-858:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1251826, https://bugzilla.redhat.com/show_bug.cgi?id=1252178, https://bugzilla.redhat.com/show_bug.cgi?id=1262625  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1251826, https://bugzilla.redhat.com/show_bug.cgi?id=1252178)


> NoSuchMethodError on JIT Compilation of non-primitive comparison
> ----------------------------------------------------------------
>
>                 Key: DROOLS-858
>                 URL: https://issues.jboss.org/browse/DROOLS-858
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Beta2
>            Reporter: Sascha Dirbach
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR1
>
>         Attachments: ConditionEvaluator898a83b4ea6745eaa1b63420a059d717.class
>
>
> A LHS like this:
> {code}
> $map : Map()
> $simpleTestObject : NonStringConstructorClass (something=="simpleTestObject")
> Entry (
>   getKey() == $simpleTestObject
> ) from $map.entrySet()
> {code}
> fails at runtime with a NoSuchMethodError, when incompatible objects are compared (Map with object vs. custom Object) and the execution is jitted.
> The generated evaluation method looks like this:
> {code}
>   public boolean evaluate(InternalFactHandle paramInternalFactHandle, InternalWorkingMemory paramInternalWorkingMemory, LeftTuple paramLeftTuple)
>   {
>     LeftTuple localLeftTuple = paramLeftTuple;
>     NonStringConstructorClass localNonStringConstructorClass2 = (NonStringConstructorClass)this.declarations[0].getValue(paramInternalWorkingMemory, localLeftTuple.getHandle().getObject());
>     Object localObject = ((Map.Entry)paramInternalFactHandle.getObject()).getKey();
>     NonStringConstructorClass localNonStringConstructorClass1 = localNonStringConstructorClass2;
>     if (localObject != null)
>     {
>       if ((localObject instanceof NonStringConstructorClass)) {
>         localObject = (NonStringConstructorClass)localObject;
>       } else {
>         localObject = new NonStringConstructorClass(localObject.toString());
>       }
>     }
>     else
>     {
>       tmpTernaryOp = (localNonStringConstructorClass1 != null ? 0 : true;
>       break label123;
>     }
>     label123:
>     return localNonStringConstructorClass1 == null ? false : ((NonStringConstructorClass)localObject).equals(localNonStringConstructorClass1);
>   }
> }
> {code}
> It seem that, a fallback for primitive types was included, by calling the constructor of an object with the object's toString() output:
> {code}
> localObject = new NonStringConstructorClass(localObject.toString());
> {code}
> At runtime this fails, if no such constructor exists.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 13 20:48:00 2015
From: issues at jboss.org (Chao Wang (JIRA))
Date: Sun, 13 Sep 2015 20:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5328) After setting
 journal-min-files to 0 through CLI server is throwing expection when
 reloading
In-Reply-To: <JIRA.12584541.1441882508000@Atlassian.JIRA>
References: <JIRA.12584541.1441882508000@Atlassian.JIRA>
	<JIRA.12584541.1441882508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584541.1441882508000.25537.1442191680623@Atlassian.JIRA>


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

Chao Wang reassigned WFLY-5328:
-------------------------------

    Assignee: Chao Wang  (was: Jeff Mesnil)


> After setting journal-min-files to 0 through CLI server is throwing expection when reloading
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5328
>                 URL: https://issues.jboss.org/browse/WFLY-5328
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>         Environment: Running unsecured EAP 7.0.0 DR9
>            Reporter: Patrik Cyprian
>            Assignee: Chao Wang
>
> When you set messaging journal-min-files to zero {{/subsystem=messaging-activemq/server=default:write-attribute(name=journal-min-files,value=0)}} , then when server is throwing exepciton *java.lang.IllegalArgumentException: minFiles cannot be less than*. In description there is no restriction for the attribute.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 01:46:00 2015
From: issues at jboss.org (Chao Wang (JIRA))
Date: Mon, 14 Sep 2015 01:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5324) in-vm acceptor/connector has
 no default value for server-id
In-Reply-To: <JIRA.12584644.1441954085000@Atlassian.JIRA>
References: <JIRA.12584644.1441954085000@Atlassian.JIRA>
	<JIRA.12584644.1441954085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584644.1441954085000.25628.1442209560301@Atlassian.JIRA>


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

Chao Wang reassigned WFLY-5324:
-------------------------------

    Assignee: Chao Wang  (was: Jeff Mesnil)


> in-vm acceptor/connector has no default value for server-id
> -----------------------------------------------------------
>
>                 Key: WFLY-5324
>                 URL: https://issues.jboss.org/browse/WFLY-5324
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Chao Wang
>
> in-vm acceptor/connector in EAP 6 has default value for server-id set to 0. But in EAP 7 no default value is set. This causes that adding in-vm acceptor/connector without server-id in CLI succeeds in EAP 6 but fails in EAP 7. We should sync default values between EAP 6 and EAP 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:00:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 14 Sep 2015 03:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.25698.1442214000546@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-282 at 9/14/15 2:59 AM:
---------------------------------------------------------

So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* mechanism type (SASL/HTTP/...)
* mechanism name (DIGEST-MD5)
* protocol (optional parameter of digest mechanims and similar - "imap" for example)
* (mapped) user name (authentication id)

_David, what should be "(mapped) name"? User name from NameCallback of sasl server?_


was (Author: honza889):
So credential mapper can look like:
{code:java}
public interface CredentialMapper {
    List<String> getCredentialNameMapping(AuthenticationInformation information);
}
{code}

The *AuthenticationInformation* will be data object which should contain:
* (mapped) user name
* mechanism type (SASL/HTTP/...)
* protocol type (optional parameter of digest mechanims and similar - "imap" for example)
* mechanism name (DIGEST-MD5)

-David, what should be "(mapped) name"? User name from NameCallback of sasl server?-

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:07:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 14 Sep 2015 03:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5324) in-vm acceptor/connector has
 no default value for server-id
In-Reply-To: <JIRA.12584644.1441954085000@Atlassian.JIRA>
References: <JIRA.12584644.1441954085000@Atlassian.JIRA>
	<JIRA.12584644.1441954085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584644.1441954085000.25710.1442214420189@Atlassian.JIRA>


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

Jeff Mesnil resolved WFLY-5324.
-------------------------------
    Resolution: Rejected


messaging-activemq's in-vm acceptor and connectors must define explicitly their server IDs.

We're moving away from having implicit default values for identifiers (eg. the name of the server must now be specified as it no longer defaults to "default).

There is no requirement to sync default values between WFLY9's messaging subsystem and WFLY10's messaging-activemq subsystem. Most of the time the value will be the same but it's not required.

> in-vm acceptor/connector has no default value for server-id
> -----------------------------------------------------------
>
>                 Key: WFLY-5324
>                 URL: https://issues.jboss.org/browse/WFLY-5324
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Chao Wang
>
> in-vm acceptor/connector in EAP 6 has default value for server-id set to 0. But in EAP 7 no default value is set. This causes that adding in-vm acceptor/connector without server-id in CLI succeeds in EAP 6 but fails in EAP 7. We should sync default values between EAP 6 and EAP 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:35:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 03:35:00 -0400 (EDT)
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.1442216061370@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584771.1442216061000.25767.1442216100402@Atlassian.JIRA>

Ladislav Thon created WFLY-5330:
-----------------------------------

             Summary: 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
            Reporter: Ladislav Thon
            Assignee: Brian Stansberry
            Priority: Blocker


When starting EAP 7.0.0.DR9 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 JBEAP-675.

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 jboss-eap-7.0.0.DR9.zip
rm jboss-eap-7.0/domain/configuration/*.xml
cp jboss-eap-6.4/domain/configuration/domain.xml jboss-eap-7.0/domain/configuration/
cp jboss-eap-6.4/domain/configuration/host.xml jboss-eap-7.0/domain/configuration/
./jboss-eap-7.0/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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:35:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 03:35:00 -0400 (EDT)
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.25770.1442216100552@Atlassian.JIRA>


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

Ladislav Thon updated WFLY-5330:
--------------------------------
    Priority: Critical  (was: Blocker)


> 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: Brian Stansberry
>            Priority: Critical
>
> When starting EAP 7.0.0.DR9 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 JBEAP-675.
> 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 jboss-eap-7.0.0.DR9.zip
> rm jboss-eap-7.0/domain/configuration/*.xml
> cp jboss-eap-6.4/domain/configuration/domain.xml jboss-eap-7.0/domain/configuration/
> cp jboss-eap-6.4/domain/configuration/host.xml jboss-eap-7.0/domain/configuration/
> ./jboss-eap-7.0/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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:35:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 03:35:00 -0400 (EDT)
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.25773.1442216100669@Atlassian.JIRA>


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

Ladislav Thon updated WFLY-5330:
--------------------------------
    Affects Version/s: 10.0.0.Beta2


> 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: Brian Stansberry
>            Priority: Critical
>
> When starting EAP 7.0.0.DR9 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 JBEAP-675.
> 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 jboss-eap-7.0.0.DR9.zip
> rm jboss-eap-7.0/domain/configuration/*.xml
> cp jboss-eap-6.4/domain/configuration/domain.xml jboss-eap-7.0/domain/configuration/
> cp jboss-eap-6.4/domain/configuration/host.xml jboss-eap-7.0/domain/configuration/
> ./jboss-eap-7.0/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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:36:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 03:36:00 -0400 (EDT)
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.25783.1442216160137@Atlassian.JIRA>


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

Ladislav Thon updated WFLY-5330:
--------------------------------
    Description: 
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}

  was:
When starting EAP 7.0.0.DR9 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 JBEAP-675.

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 jboss-eap-7.0.0.DR9.zip
rm jboss-eap-7.0/domain/configuration/*.xml
cp jboss-eap-6.4/domain/configuration/domain.xml jboss-eap-7.0/domain/configuration/
cp jboss-eap-6.4/domain/configuration/host.xml jboss-eap-7.0/domain/configuration/
./jboss-eap-7.0/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}



> 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: Brian Stansberry
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:39:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 14 Sep 2015 03:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5324) in-vm acceptor/connector has
 no default value for server-id
In-Reply-To: <JIRA.12584644.1441954085000@Atlassian.JIRA>
References: <JIRA.12584644.1441954085000@Atlassian.JIRA>
	<JIRA.12584644.1441954085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584644.1441954085000.25799.1442216340107@Atlassian.JIRA>


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

Miroslav Novak commented on WFLY-5324:
--------------------------------------

I did comparison of models between EAP 6 (HornetQ) and EAP 7 (Artemis). This was the only change in default value I've found.  

> in-vm acceptor/connector has no default value for server-id
> -----------------------------------------------------------
>
>                 Key: WFLY-5324
>                 URL: https://issues.jboss.org/browse/WFLY-5324
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Miroslav Novak
>            Assignee: Chao Wang
>
> in-vm acceptor/connector in EAP 6 has default value for server-id set to 0. But in EAP 7 no default value is set. This causes that adding in-vm acceptor/connector without server-id in CLI succeeds in EAP 6 but fails in EAP 7. We should sync default values between EAP 6 and EAP 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:40:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 03:40:00 -0400 (EDT)
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.25804.1442216400416@Atlassian.JIRA>


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

Ladislav Thon commented on WFLY-5330:
-------------------------------------

I'm tentatively assigning to Stuart, as he also dealt with WFLY-5092, which was a standalone counterpart of this. [~swd847], please shout if you're tired of me assigning these migration issues to you :-)

> 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: Brian Stansberry
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:41:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 03:41:00 -0400 (EDT)
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.25811.1442216460414@Atlassian.JIRA>


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

Ladislav Thon reassigned WFLY-5330:
-----------------------------------

    Assignee: Stuart Douglas  (was: Brian Stansberry)


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:41:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 03:41:00 -0400 (EDT)
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.25818.1442216460669@Atlassian.JIRA>


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

Ladislav Thon updated WFLY-5306:
--------------------------------
    Priority: Major  (was: Critical)


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 03:58:00 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 03:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.25856.1442217480113@Atlassian.JIRA>


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

?? ? commented on DROOLS-880:
-----------------------------

Hello, Edson. I want to know the status of issue.
Thank you.

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 04:29:00 2015
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Mon, 14 Sep 2015 04:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4433) Potential deadlock on server
	shutdown
In-Reply-To: <JIRA.12565951.1426498445000@Atlassian.JIRA>
References: <JIRA.12565951.1426498445000@Atlassian.JIRA>
	<JIRA.12565951.1426498445000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565951.1426498445000.25916.1442219340144@Atlassian.JIRA>


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

Thomas Diesler resolved WFLY-4433.
----------------------------------
    Resolution: Out of Date


Out of Date

> Potential deadlock on server shutdown
> -------------------------------------
>
>                 Key: WFLY-4433
>                 URL: https://issues.jboss.org/browse/WFLY-4433
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.2.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> There is a rare condition where the server shutdown hangs forever. It may be related to the lock on 0x00000000c6ac9800
> {code}
> [0m[0m12:05:00,818 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment example-camel-activemq-2.2.0-SNAPSHOT.war (runtime-name: example-camel-activemq-2.2.0-SNAPSHOT.war) in 1783ms
> [0m[0m12:05:06,337 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment hawtio-1.4.42.war (runtime-name: hawtio-1.4.42.war) in 7281ms
> [0m[0m12:05:06,346 INFO  [org.jboss.as] (MSC service thread 1-3) JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 7297ms
> [0m2015-03-16 05:25:01
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode):
> "Thread-14" #38 daemon prio=5 os_prio=0 tid=0x00007f63b6708000 nid=0x13ad waiting for monitor entry [0x00007f6394154000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- waiting to lock <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "Thread-13" #37 daemon prio=5 os_prio=0 tid=0x00007f63b465f000 nid=0x13ab in Object.wait() [0x00007f63814d1000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
> 	- locked <0x00000000c6ac92b0> (a java.lang.Object)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.close(RemotingModelControllerClient.java:100)
> 	- locked <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.wildfly.plugin.common.IoUtils.safeClose(IoUtils.java:37)
> 	at org.wildfly.plugin.server.StandaloneServer.stopServer(StandaloneServer.java:77)
> 	at org.wildfly.plugin.server.Server.stop(Server.java:108)
> 	- locked <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
> 	at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
> 	at java.lang.Thread.run(Thread.java:745)
> "pool-2-thread-1" #45 prio=5 os_prio=0 tid=0x00007f63b5c43800 nid=0x110d waiting for monitor entry [0x00007f6394a5d000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:116)
> 	- waiting to lock <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.wildfly.plugin.server.StandaloneServer.checkServerState(StandaloneServer.java:149)
> 	at org.wildfly.plugin.server.Server$Reaper.run(Server.java:195)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 	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
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 05:12:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Sep 2015 05:12:00 -0400 (EDT)
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.26047.1442221920319@Atlassian.JIRA>


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

Ladislav Thon commented on WFLY-5330:
-------------------------------------

Just verified that this also happens with current WildFly master, tested with commit 459b2411c2.

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 05:26:00 2015
From: issues at jboss.org (=?UTF-8?Q?Petr_S=C3=ADgl_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 05:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5331)
 ConcurrentModificationException in InfinispanSessionManager.findListeners
In-Reply-To: <JIRA.12584785.1442222719000@Atlassian.JIRA>
References: <JIRA.12584785.1442222719000@Atlassian.JIRA>
	<JIRA.12584785.1442222719905@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584785.1442222719000.26091.1442222760180@Atlassian.JIRA>

Petr S?gl created WFLY-5331:
-------------------------------

             Summary: ConcurrentModificationException in InfinispanSessionManager.findListeners
                 Key: WFLY-5331
                 URL: https://issues.jboss.org/browse/WFLY-5331
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 9.0.1.Final
            Reporter: Petr S?gl
            Assignee: Paul Ferraro
            Priority: Critical


Configuration - standalone-ha.xml:

{noformat}
            <cache-container name="web" default-cache="repl" module="org.wildfly.clustering.web.infinispan">
                <transport lock-timeout="60000"/>
                <replicated-cache name="repl" mode="ASYNC">
                    <locking isolation="READ_COMMITTED"/>
                    <transaction locking="OPTIMISTIC"/>
                    <file-store/>
                </replicated-cache>
            </cache-container>
{noformat}

After user is logged out, we invalidate session and show login page. Problem is, that sometimes server crashed with ConcurrentModificationException.

{noformat}
2015-09-10 08:55:24,571 ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /blabla/login: java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
	at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:400)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:387)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:245)
	at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:723)
	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:753)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:64)
	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:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

2015-09-10 08:55:24,574 ERROR [cz.blabla.portal.error.ErrorHelper] (default task-10) HTTP error code 500 -> redirecting to default ERROR PAGE. Cause: null: java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
	at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:400)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:387)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:245)
	at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:723)
	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:753)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:64)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
{noformat}

I think, that problem is in method InfinispanSessionManager.findListeners.

We have fix it with not very nice try - catch, maybe better way is to copy collection of names and iterate over it... I know it is not very nice and to be honest, I don't know if it is "right", but better then error page after logout :-).

{noformat}
    private static List<HttpSessionActivationListener> findListeners(ImmutableSession session) {
    	List<HttpSessionActivationListener> listeners = new ArrayList<>();        
        try {
	        ImmutableSessionAttributes attributes = session.getAttributes();
	        Set<String> names = attributes.getAttributeNames();
	        if (names != null && !names.isEmpty()) {
			    for (String name: names) {
			        Object attribute = attributes.getAttribute(name);
			        if (attribute instanceof HttpSessionActivationListener) {
			            listeners.add((HttpSessionActivationListener) attribute);
			        }
			    }
	        }
        } catch (Exception e) {
        	InfinispanWebLogger.ROOT_LOGGER.tracef("No session attributes found.", e);
        }
        return listeners;
    }
{noformat}





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 05:27:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Mon, 14 Sep 2015 05:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5079) Removing non existent mail
 server with standard name (via CLI) doesn't fail even though it should
In-Reply-To: <JIRA.12580941.1439373968000@Atlassian.JIRA>
References: <JIRA.12580941.1439373968000@Atlassian.JIRA>
	<JIRA.12580941.1439373968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580941.1439373968000.26099.1442222820081@Atlassian.JIRA>


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

Radim Hatlapatka commented on WFLY-5079:
----------------------------------------

The issue seems to be caused by {{org.jboss.as.mail.extension.MailSessionDefinition#getChildren}}, which returns list of the standard mail servers. These children are always registered on reload even when the mail server was removed in previous step.

> Removing non existent mail server with standard name (via CLI) doesn't fail even though it should
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5079
>                 URL: https://issues.jboss.org/browse/WFLY-5079
>             Project: WildFly
>          Issue Type: Bug
>          Components: Mail
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Radim Hatlapatka
>            Assignee: Tomaz Cerar
>
> Removing non-existent mail server (which is named smtp or pop3 or imap) via CLI operation doesn't fail even though it should.
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:add(jndi-name=java\:jboss\/mail\/test1439373303651)
> {"outcome" => "success"}
>  /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651:read-children-names(child-type=server)
> {
>     "outcome" => "success",
>     "result" => []
> }
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=smtp:remove
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {noformat}
> Note: trying to remove non-existent server named e.g. {{xxx}} correctly fails see
> {noformat}
> /subsystem=mail/mail-session=java\:jboss\/mail\/test1439373303651/server=xxx:remove
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0030: No resource definition is registered for address [
>     (\"subsystem\" => \"mail\"),
>     (\"mail-session\" => \"java:jboss/mail/test1439373303651\"),
>     (\"server\" => \"xxx\")
> ]",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 06:30:00 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Mon, 14 Sep 2015 06:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574263@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.26232.1442226600186@Atlassian.JIRA>

Panagiotis Sotiropoulos created WFLY-5332:
---------------------------------------------

             Summary: Allow configure max-threads and core-threads independently
                 Key: WFLY-5332
                 URL: https://issues.jboss.org/browse/WFLY-5332
             Project: WildFly
          Issue Type: Feature Request
          Components: EJB
            Reporter: Panagiotis Sotiropoulos
            Assignee: Panagiotis Sotiropoulos


Description of problem (Pasting the description from https://bugzilla.redhat.com/show_bug.cgi?id=1255494):
It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.

ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java

I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 06:31:00 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Mon, 14 Sep 2015 06:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.26234.1442226660137@Atlassian.JIRA>


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

Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
    Description: 
Description of problem:
It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.

ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java

I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.

  was:
Description of problem (Pasting the description from https://bugzilla.redhat.com/show_bug.cgi?id=1255494):
It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.

ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java

I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.



> Allow configure max-threads and core-threads independently
> ----------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 06:31:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 14 Sep 2015 06:31:00 -0400 (EDT)
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.26238.1442226660258@Atlassian.JIRA>


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

Jeff Mesnil resolved WFLY-5187.
-------------------------------
    Fix Version/s: 10.0.0.CR1
       Resolution: Done


Upstream bug was fixed in Artemis 1.1.0-wildfly-5

> 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
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 06:33:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Sep 2015 06:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.26241.1442226780115@Atlassian.JIRA>


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

RH Bugzilla Integration updated WFLY-5332:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1255494
        Bugzilla Update: Perform


> Allow configure max-threads and core-threads independently
> ----------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 07:13:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 14 Sep 2015 07:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5094) Cluster error
In-Reply-To: <JIRA.12581049.1439412204000@Atlassian.JIRA>
References: <JIRA.12581049.1439412204000@Atlassian.JIRA>
	<JIRA.12581049.1439412204000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581049.1439412204000.26324.1442229180228@Atlassian.JIRA>


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

Jeff Mesnil resolved WFLY-5094.
-------------------------------
    Resolution: Rejected


Cluster authentication must be configured when starting the nodes: https://docs.jboss.org/author/display/WFLY8/Messaging+configuration#Messagingconfiguration-ClusterAuthentication

> Cluster error
> -------------
>
>                 Key: WFLY-5094
>                 URL: https://issues.jboss.org/browse/WFLY-5094
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 9.0.1.Final
>         Environment: POC
>            Reporter: noorulla shaik
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> i am getitng cluster error while starting Slave servers.
>  HQ224018: Failed to create session: HornetQClusterSecurityException[errorType=CLUSTER_SECURITY_EXCEPTION message=HQ119099: Unable to authenticate cluster user: HORNETQ.CLUSTER.ADMIN.USER]
> [Server:server-two]     at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:122)
> [Server:server-two]     at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:1020)
> [Server:server-two]     at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:149)
> [Server:server-two]     at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:77)
> [Server:server-two]     at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:641)
> [Server:server-two]     at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:523)
> [Server:server-two]     at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:502)
> [Server:server-two]     at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:669)
> [Server:server-two]     at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.channelRead(HornetQChannelHandler.java:73)
> [Server:server-two]     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> [Server:server-two]     at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> [Server:server-two]     at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> [Server:server-two]     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> [Server:server-two]     at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> [Server:server-two]     at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
> [Server:server-two]     at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> [Server:server-two]     at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> [Server:server-two]     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> [Server:server-two]     at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> [Server:server-two]     at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> [Server:server-two]     at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> [Server:server-two]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 07:34:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 14 Sep 2015 07:34:00 -0400 (EDT)
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.26414.1442230440537@Atlassian.JIRA>


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

Jeff Mesnil resolved WFLY-5142.
-------------------------------
    Resolution: Done


Security configuration to allow guest connection from JMS clients: https://issues.jboss.org/browse/WFLY-5142?focusedCommentId=13106402

> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 07:45:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 07:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5333) Happen to se
 org.omg.CORBA.PolicyError: There is no PolicyFactory time to time
In-Reply-To: <JIRA.12584807.1442231081000@Atlassian.JIRA>
References: <JIRA.12584807.1442231081000@Atlassian.JIRA>
	<JIRA.12584807.1442231081336@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584807.1442231081000.26455.1442231100557@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5333:
--------------------------------------

             Summary: Happen to se org.omg.CORBA.PolicyError: There is no PolicyFactory time to time
                 Key: WFLY-5333
                 URL: https://issues.jboss.org/browse/WFLY-5333
             Project: WildFly
          Issue Type: Bug
          Components: IIOP
            Reporter: Ond?ej Chaloupka
            Assignee: Tomasz Adamski


I happens to me that I can see time to time error {{org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type}} [1].

I can see this issue during deployment 
Unfortunately it's intermittent failure that I'm not able to reproduce surely. In most cases the server starts fine (and tests run without any problem).

This happens normally on server which is used as target of iiop call from other server.
Adding the server log for further reference.

[1]
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."crashrecovery-txpropag-server.jar".component.MultiXACrashBean.EjbIIOPService: org.jboss.msc.service.StartException in service jboss.deployment.unit."crashrecovery-txpropag-server.jar".component.MultiXACrashBean.EjbIIOPService: org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type -2023406815
 at org.jboss.as.ejb3.iiop.EjbIIOPService.start(EjbIIOPService.java:398)
 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: org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type -2023406815
 at com.sun.corba.se.impl.interceptors.PIHandlerImpl.create_policy(PIHandlerImpl.java:955)
 at com.sun.corba.se.impl.orb.ORBImpl.create_policy(ORBImpl.java:1611)
 at org.jboss.as.ejb3.iiop.EjbIIOPService.start(EjbIIOPService.java:291)
 ... 5 more
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 07:45:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 07:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5333) Happen to se
 org.omg.CORBA.PolicyError: There is no PolicyFactory time to time
In-Reply-To: <JIRA.12584807.1442231081000@Atlassian.JIRA>
References: <JIRA.12584807.1442231081000@Atlassian.JIRA>
	<JIRA.12584807.1442231081000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584807.1442231081000.26458.1442231100706@Atlassian.JIRA>


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

Ond?ej Chaloupka updated WFLY-5333:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> Happen to se org.omg.CORBA.PolicyError: There is no PolicyFactory time to time
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-5333
>                 URL: https://issues.jboss.org/browse/WFLY-5333
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>
> I happens to me that I can see time to time error {{org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type}} [1].
> I can see this issue during deployment 
> Unfortunately it's intermittent failure that I'm not able to reproduce surely. In most cases the server starts fine (and tests run without any problem).
> This happens normally on server which is used as target of iiop call from other server.
> Adding the server log for further reference.
> [1]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."crashrecovery-txpropag-server.jar".component.MultiXACrashBean.EjbIIOPService: org.jboss.msc.service.StartException in service jboss.deployment.unit."crashrecovery-txpropag-server.jar".component.MultiXACrashBean.EjbIIOPService: org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type -2023406815
>  at org.jboss.as.ejb3.iiop.EjbIIOPService.start(EjbIIOPService.java:398)
>  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: org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type -2023406815
>  at com.sun.corba.se.impl.interceptors.PIHandlerImpl.create_policy(PIHandlerImpl.java:955)
>  at com.sun.corba.se.impl.orb.ORBImpl.create_policy(ORBImpl.java:1611)
>  at org.jboss.as.ejb3.iiop.EjbIIOPService.start(EjbIIOPService.java:291)
>  ... 5 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 07:47:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 07:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5333) Happen to se
 org.omg.CORBA.PolicyError: There is no PolicyFactory time to time
In-Reply-To: <JIRA.12584807.1442231081000@Atlassian.JIRA>
References: <JIRA.12584807.1442231081000@Atlassian.JIRA>
	<JIRA.12584807.1442231081000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584807.1442231081000.26472.1442231220349@Atlassian.JIRA>


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

Ond?ej Chaloupka commented on WFLY-5333:
----------------------------------------

As said I'm not able to reproduce it somehow easily. But if there is a way how to get some useful logs or something similar I will be happy to try to get them (in case of error occurs).

> Happen to se org.omg.CORBA.PolicyError: There is no PolicyFactory time to time
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-5333
>                 URL: https://issues.jboss.org/browse/WFLY-5333
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>
> I happens to me that I can see time to time error {{org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type}} [1].
> I can see this issue during deployment 
> Unfortunately it's intermittent failure that I'm not able to reproduce surely. In most cases the server starts fine (and tests run without any problem).
> This happens normally on server which is used as target of iiop call from other server.
> Adding the server log for further reference.
> [1]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."crashrecovery-txpropag-server.jar".component.MultiXACrashBean.EjbIIOPService: org.jboss.msc.service.StartException in service jboss.deployment.unit."crashrecovery-txpropag-server.jar".component.MultiXACrashBean.EjbIIOPService: org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type -2023406815
>  at org.jboss.as.ejb3.iiop.EjbIIOPService.start(EjbIIOPService.java:398)
>  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: org.omg.CORBA.PolicyError: There is no PolicyFactory Registered for type -2023406815
>  at com.sun.corba.se.impl.interceptors.PIHandlerImpl.create_policy(PIHandlerImpl.java:955)
>  at com.sun.corba.se.impl.orb.ORBImpl.create_policy(ORBImpl.java:1611)
>  at org.jboss.as.ejb3.iiop.EjbIIOPService.start(EjbIIOPService.java:291)
>  ... 5 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 08:38:00 2015
From: issues at jboss.org (Manuel Colchete (JIRA))
Date: Mon, 14 Sep 2015 08:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener don't
 request client certificate when verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.26681.1442234280290@Atlassian.JIRA>


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

Manuel Colchete updated WFLY-5256:
----------------------------------
    Summary: HTTPS undertow listener don't request client certificate when verify-client=NOT_REQUESTED  (was: HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED)


> HTTPS undertow listener don't request client certificate when verify-client=NOT_REQUESTED
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5256
>                 URL: https://issues.jboss.org/browse/WFLY-5256
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Manuel Colchete
>            Assignee: Stuart Douglas
>
> HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access secured resource as first, it don't requested certificate and return HTTP status 403.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 08:46:00 2015
From: issues at jboss.org (Manuel Colchete (JIRA))
Date: Mon, 14 Sep 2015 08:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5256) HTTPS undertow listener don't
 request client certificate when verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12583490.1441140366000@Atlassian.JIRA>
References: <JIRA.12583490.1441140366000@Atlassian.JIRA>
	<JIRA.12583490.1441140366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583490.1441140366000.26716.1442234760238@Atlassian.JIRA>


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

Manuel Colchete commented on WFLY-5256:
---------------------------------------

I'm sorry I cloned the issue and not updated the title.

The problem is that when verify-client is configured with NOT_REQUESTED, and a resource that uses CLIENT-CERT authentication is accessed, the certificate is not required and returns a 403 status.

Please see [https://developer.jboss.org/thread/262364] for details.

Thank you.

> HTTPS undertow listener don't request client certificate when verify-client=NOT_REQUESTED
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5256
>                 URL: https://issues.jboss.org/browse/WFLY-5256
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Manuel Colchete
>            Assignee: Stuart Douglas
>
> HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access secured resource as first, it don't requested certificate and return HTTP status 403.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 08:47:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 14 Sep 2015 08:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4515) Fix clustering transformers
 and reenable in mixed-domain tests
In-Reply-To: <JIRA.12568394.1429024821000@Atlassian.JIRA>
References: <JIRA.12568394.1429024821000@Atlassian.JIRA>
	<JIRA.12568394.1429024821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568394.1429024821000.26722.1442234820271@Atlassian.JIRA>


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

Radoslav Husar commented on WFLY-4515:
--------------------------------------

Another set:

backups are not rejected

{noformat}
    (\"subsystem\" => \"infinispan\"),
    (\"cache-container\" => \"maximal\"),
    (\"replicated-cache\" => \"repl\"),
    (\"component\" => \"backups\"),
    (\"backup\" => \"NYC\")
] is rejected on the target host and will need to be ignored on the host"
{noformat}


table=binary and similar, don't seem to be translated to the legacy attribute

{noformat}
: {
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0304: Operation {
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"infinispan\"),
        (\"cache-container\" => \"maximal\"),
        (\"distributed-cache\" => \"dist\"),
        (\"mixed-keyed-jdbc-store\" => \"MIXED_KEYED_JDBC_STORE\"),
        (\"table\" => \"binary\")
    ],
    \"prefix\" => \"ispn_entry\",
    \"batch-size\" => 100,
    \"fetch-size\" => 100,
    \"id-column\" => {
        \"name\" => \"id\",
        \"type\" => \"VARCHAR\"
    },
    \"data-column\" => {
        \"name\" => \"datum\",
        \"type\" => \"BINARY\"
    },
    \"timestamp-column\" => {
        \"name\" => \"version\",
        \"type\" => \"BIGINT\"
    }
} at [
    (\"subsystem\" => \"infinispan\"),
    (\"cache-container\" => \"maximal\"),
    (\"distributed-cache\" => \"dist\"),
    (\"mixed-keyed-jdbc-store\" => \"MIXED_KEYED_JDBC_STORE\"),
    (\"table\" => \"binary\")
] is rejected on the target host and will need to be ignored on the host"
} expected:<[success]> but was:<[failed]>
{noformat}


> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
>                 Key: WFLY-4515
>                 URL: https://issues.jboss.org/browse/WFLY-4515
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Kabir Khan
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. 
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> 	mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
>    ("profile" => "full-ha"),
>    ("subsystem" => "infinispan"),
>    ("cache-container" => "server"),
>    ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> 	/subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ThreadsAttributesWriteHandler.java#L61 so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 08:49:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Mon, 14 Sep 2015 08:49:00 -0400 (EDT)
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.26729.1442234940252@Atlassian.JIRA>


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

Tomasz Adamski reassigned WFLY-5153:
------------------------------------

    Fix Version/s: 10.0.0.CR1
         Assignee: Ond?ej Chaloupka  (was: Tomasz Adamski)
       Resolution: Done


> 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: Ond?ej Chaloupka
>            Assignee: Ond?ej 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
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 08:51:00 2015
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Mon, 14 Sep 2015 08:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5179) Some tests are unable to init
 arquillian protocol with security manager
In-Reply-To: <JIRA.12582301.1440411788000@Atlassian.JIRA>
References: <JIRA.12582301.1440411788000@Atlassian.JIRA>
	<JIRA.12582301.1440411788000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582301.1440411788000.26744.1442235060424@Atlassian.JIRA>


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

Ondrej Kotek reassigned WFLY-5179:
----------------------------------

    Assignee: Ondrej Kotek  (was: Josef Cacek)


> Some tests are unable to init arquillian protocol with security manager
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5179
>                 URL: https://issues.jboss.org/browse/WFLY-5179
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Ondrej Kotek
>
> *Description of problem:*
> Some tests are unable to init arquillian protocol with security manager.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testEjbLink
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testLookup
> * org.jboss.as.test.integration.ee.injection.resource.enventry.EnvEntryInjectionTestCase#testEnvEntryInjectionIntoServlet
> * org.jboss.as.test.integration.ejb.security.AuthenticationTestCase
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction
> *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=EjbLocalRefInjectionTestCase
> *Actual results:*
> {noformat}
> java.lang.RuntimeException: Could not init arquillian protocol
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> 	at org.xnio.Xnio.getInstance(Xnio.java:193)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:122)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> 	at org.jboss.as.arquillian.container.ManagementClient.init(ManagementClient.java:140)
> 	at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:177)
> 	at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.performCall(EjbLocalRefInjectionTestCase.java:62)
> 	at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.testEjbLink(EjbLocalRefInjectionTestCase.java:73)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 08:57:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 14 Sep 2015 08:57:00 -0400 (EDT)
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.1442235373677@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584816.1442235373000.26761.1442235420189@Atlassian.JIRA>

Heiko Braun created WFLY-5334:
---------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 09:03:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 14 Sep 2015 09:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-869) command line option to turn
 off CLI security prompts in non-interactive mode
In-Reply-To: <JIRA.12580481.1438858498000@Atlassian.JIRA>
References: <JIRA.12580481.1438858498000@Atlassian.JIRA>
	<JIRA.12580481.1438858498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580481.1438858498000.26785.1442235780802@Atlassian.JIRA>


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

Alexey Loubyansky resolved WFCORE-869.
--------------------------------------
    Fix Version/s: 2.0.0.CR1
       Resolution: Done


Yes, https://github.com/wildfly/wildfly-core/pull/1048 resolves this issue.
The input can be disabled now with --error-on-interact jboss-cli.[sh|bat] argument.

> command line option to turn off CLI security prompts in non-interactive mode
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-869
>                 URL: https://issues.jboss.org/browse/WFCORE-869
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Bartosz Spyrko-?mietanko
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.CR1
>
>
> When the management interface is secured using a SSL certificate and the certificate is not trusted by the client, user is shown following dialog to accept the certificate:
> {{Accept certificate? [N]o, [T]emporarily, [P]ermenantly : }}
> The prompt is also shown in non-interactive mode (using --file or --command). If the CLI call is a part of an automated process, this can lead to the process being blocked waiting for user input that never happens.
> If the jboss-cli is executed in non-interactive mode and the SSL certificate is not trusted, process should immediately fail with appropriate message. Username/password authentication prompt already works in this way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 09:06:00 2015
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Mon, 14 Sep 2015 09:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-909) LdapLoginModule code has
 unnecessary BIND_CREDENTIAL constant
In-Reply-To: <JIRA.12582404.1440488382000@Atlassian.JIRA>
References: <JIRA.12582404.1440488382000@Atlassian.JIRA>
	<JIRA.12582404.1440488382000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582404.1440488382000.26791.1442235960343@Atlassian.JIRA>


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

Peter Skopek reassigned SECURITY-909:
-------------------------------------

    Assignee: Peter Skopek  (was: Stefan Guilhen)


> LdapLoginModule code has unnecessary BIND_CREDENTIAL constant
> -------------------------------------------------------------
>
>                 Key: SECURITY-909
>                 URL: https://issues.jboss.org/browse/SECURITY-909
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX
>            Reporter: Josef Cacek
>            Assignee: Peter Skopek
>            Priority: Minor
>
> The {{org.jboss.security.auth.spi.LdapLoginModule}} class contains unnecessary constant
> {code}
> private static final String BIND_CREDENTIAL = "bindCredential";
> {code}
> It's only used in {{traceLDAPEnv}} method which is responsible for masking passwords in module options. The "bindCredential" is not a valid option in this login module.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 09:27:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Mon, 14 Sep 2015 09:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5335) Singleton deployment of
 clusterbench test application fails
In-Reply-To: <JIRA.12584821.1442237134000@Atlassian.JIRA>
References: <JIRA.12584821.1442237134000@Atlassian.JIRA>
	<JIRA.12584821.1442237134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584821.1442237134000.26861.1442237220321@Atlassian.JIRA>


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

Michal Vinkler moved JBEAP-1067 to WFLY-5335:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5335  (was: JBEAP-1067)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Clustering
                           (was: Clustering)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.Beta1
                           (was: 7.0.0.DR9)


> Singleton deployment of clusterbench test application fails
> -----------------------------------------------------------
>
>                 Key: WFLY-5335
>                 URL: https://issues.jboss.org/browse/WFLY-5335
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>            Priority: Blocker
>
> When trying to deploy our clustering test application "clusterbench" as a singleton deployment, server boot fails in an unrecoverable manner.
> To identify clusterbench-ee7.ear as a singleton deployment, I added singleton-deployment.xml deployment descriptor into deployment /META-INF/ folder. The modified clusterbench-ee7.ear is attached.
> The same issue occurs when trying with latest wildfly upstream/master bits. 
> Server logs:
> {code:title=Server 1}
> [mvinkler at localhost jboss-eap-7.0_1]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_1
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 14:49:40,976 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 14:49:41,156 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 14:49:41,204 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 14:49:41,957 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 2) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 14:49:41,962 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment clusterbench-ee7.ear
> 14:49:41,979 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 30) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/data/content/b4/8714b2fc6cba3b7ba7fac5e1100c85dc0a36ce/content
> 14:49:42,052 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 14:49:42,073 INFO  [org.xnio] (MSC service thread 1-6) XNIO version 3.4.0.Beta1
> 14:49:42,078 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.4.0.Beta1
> 14:49:42,100 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 4.0.9.Final
> 14:49:42,107 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 14:49:42,111 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 14:49:42,116 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 14:49:42,212 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 14:49:42,231 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 14:49:42,233 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 14:49:42,245 INFO  [org.jboss.as.connector] (MSC service thread 1-5) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 14:49:42,248 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 14:49:42,249 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 14:49:42,254 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 14:49:42,253 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 14:49:42,264 INFO  [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 14:49:42,310 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:42,311 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:42,339 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 14:49:42,339 INFO  [org.jboss.as.naming] (MSC service thread 1-4) WFLYNAM0003: Starting Naming Service
> 14:49:42,419 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_1/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 14:49:42,429 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
> 14:49:42,431 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0018: Host default-host starting
> 14:49:42,485 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080
> 14:49:42,487 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8009
> 14:49:42,490 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 14:49:42,511 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 14:49:42,597 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 14:49:42,641 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/deployments
> 14:49:42,647 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "clusterbench-ee7.ear" (runtime-name: "clusterbench-ee7.ear")
> 14:49:42,723 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 14:49:42,726 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-passivating.war")
> 14:49:42,726 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-ejb.jar")
> 14:49:42,727 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-default.war")
> 14:49:42,847 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-7) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-default.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:42,852 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:43,066 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:43,066 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:43,067 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:43,067 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:46,454 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000078: Starting JGroups channel server
> 14:49:46,464 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000094: Received new cluster view for channel server: [node1|0] (1) [node1]
> 14:49:46,467 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000079: Channel server local address is node1, physical addresses are [127.0.0.1:55200]
> 14:49:46,471 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 14:49:46,595 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started default cache from server container
> 14:49:46,625 INFO  [org.wildfly.clustering.server] (ServerService Thread Pool -- 64) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."clusterbench-ee7.ear".FIRST_MODULE_USE service
> 14:49:48,948 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,ee,node1) ISPN000094: Received new cluster view for channel server: [node1|1] (2) [node1, node2]
> 14:49:49,477 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=1, rebalanceId=1, currentCH=ReplicatedConsistentHash{ns = 60, owners = (1)[node1: 60]}, pendingCH=ReplicatedConsistentHash{ns = 60, owners = (2)[node1: 30, node2: 30]}, unionCH=null, actualMembers=[node1, node2]}
> 14:54:42,636 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]'
> 14:54:42,695 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 57ms
> 14:54:42,695 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 57ms
> 14:54:42,695 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000336: Finished cluster-wide rebalance for cache default, topology id = 1
> 14:54:42,698 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0003: Stopped default cache from server container
> 14:54:42,699 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 61ms
> 14:54:42,701 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel server
> 14:54:42,702 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel server
> 14:54:42,707 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 69ms
> 14:54:42,716 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0022: Deploy of deployment "clusterbench-ee7.ear" was rolled back with no failure message
> 14:54:42,718 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> 14:54:42,721 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 39) MODCLUSTER000002: Initiating mod_cluster shutdown
> 14:54:42,719 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow AJP listener ajp suspending
> 14:54:42,722 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 14:54:42,723 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 14:54:42,722 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 14:54:42,724 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> 14:54:42,728 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> 14:54:42,728 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 14:54:42,747 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 14:54:42,752 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 14:54:42,765 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 9ms
> {code}
> {code:title=Server 2}
> [mvinkler at localhost jboss-eap-7.0_2]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_2
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 14:49:46,623 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 14:49:46,835 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 14:49:46,883 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 14:49:47,735 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 14:49:47,851 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 14:49:47,866 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.4.0.Beta1
> 14:49:47,874 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.4.0.Beta1
> 14:49:47,908 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.9.Final
> 14:49:47,909 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 14:49:47,916 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 14:49:47,997 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 14:49:47,999 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 14:49:48,016 INFO  [org.jboss.as.connector] (MSC service thread 1-5) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 14:49:48,024 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 14:49:48,027 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 14:49:48,028 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 14:49:48,034 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 14:49:48,059 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 14:49:48,079 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 14:49:48,085 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:48,088 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:48,111 INFO  [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 14:49:48,123 INFO  [org.jboss.as.naming] (MSC service thread 1-5) WFLYNAM0003: Starting Naming Service
> 14:49:48,123 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-8) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 14:49:48,188 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_2/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 14:49:48,191 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0012: Started server default-server.
> 14:49:48,192 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0018: Host default-host starting
> 14:49:48,236 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8109
> 14:49:48,240 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8180
> 14:49:48,243 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 14:49:48,256 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 14:49:48,358 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 14:49:48,423 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/deployments
> 14:49:48,434 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "clusterbench-ee7.ear" (runtime-name: "clusterbench-ee7.ear")
> 14:49:48,515 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-passivating.war")
> 14:49:48,515 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-ejb.jar")
> 14:49:48,515 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-default.war")
> 14:49:48,530 INFO  [org.jboss.ws.common.management] (MSC service thread 1-3) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 14:49:48,661 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:48,664 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-default.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:48,875 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:48,875 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:48,876 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:48,876 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:49,291 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000078: Starting JGroups channel server
> 14:49:49,299 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000094: Received new cluster view for channel server: [node1|1] (2) [node1, node2]
> 14:49:49,302 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000079: Channel server local address is node2, physical addresses are [127.0.0.1:55300]
> 14:49:49,345 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 14:50:49,523 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 64) MSC000001: Failed to start service jboss.infinispan.server.default: org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>         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.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>         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.ComponentRegistry.start(ComponentRegistry.java:218)
>         at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
>         at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
>         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: Initial state transfer timed out for cache default on node2
>         at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
>         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)
>         ... 19 more
> 14:50:49,526 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:50:49,529 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "infinispan"),
>     ("cache-container" => "server"),
>     ("replicated-cache" => "default")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.infinispan.server.default" => "org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>     Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>     Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache default on node2"}}
> 14:50:49,557 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 14:50:49,559 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.infinispan.server.default: org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> 14:50:49,642 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:10090/management
> 14:50:49,643 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:10090
> 14:50:49,643 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started (with errors) in 63233ms - Started 321 of 583 services (7 services failed or missing dependencies, 363 services are lazy, passive or on-demand)
> 14:51:49,528 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:52:49,529 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:53:49,531 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:54:42,713 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|2] (1) [node2]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 09:31:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 14 Sep 2015 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5336) Publish diffs online of
 master's model with the legacy versions
In-Reply-To: <JIRA.12584823.1442237429000@Atlassian.JIRA>
References: <JIRA.12584823.1442237429000@Atlassian.JIRA>
	<JIRA.12584823.1442237429425@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584823.1442237429000.26877.1442237460220@Atlassian.JIRA>

Kabir Khan created WFLY-5336:
--------------------------------

             Summary: Publish diffs online of master's model with the legacy versions
                 Key: WFLY-5336
                 URL: https://issues.jboss.org/browse/WFLY-5336
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Kabir Khan
            Assignee: Tomaz Cerar


[Sep-13 13:05] Kabir Khan: I'll just ask now when I remember, no need to look today - but do you think we can set up a brontes job which runs CompareModelVersionUtils and publishes the results somewhere? The 'publishing the results somewhere' is the tricky bit, although we could perhaps use some git repository for that

Monday September 14, 2015
[15:25] Tomaz Cerar: hey
sorry for late replay, i am on pto this week...
but what you ask for is doable
either by ftp upload
or probably even easier
to use github pages
and have tamcity do commit + push
to some repo




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 09:33:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Mon, 14 Sep 2015 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5335) Singleton deployment of
 clusterbench test application fails
In-Reply-To: <JIRA.12584821.1442237134000@Atlassian.JIRA>
References: <JIRA.12584821.1442237134000@Atlassian.JIRA>
	<JIRA.12584821.1442237134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584821.1442237134000.26883.1442237580270@Atlassian.JIRA>


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

Michal Vinkler updated WFLY-5335:
---------------------------------
    Affects Version/s: 10.0.0.Beta2
                           (was: 10.0.0.Beta1)


> Singleton deployment of clusterbench test application fails
> -----------------------------------------------------------
>
>                 Key: WFLY-5335
>                 URL: https://issues.jboss.org/browse/WFLY-5335
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>            Priority: Blocker
>
> When trying to deploy our clustering test application "clusterbench" as a singleton deployment, server boot fails in an unrecoverable manner.
> To identify clusterbench-ee7.ear as a singleton deployment, I added singleton-deployment.xml deployment descriptor into deployment /META-INF/ folder. The modified clusterbench-ee7.ear is attached.
> The same issue occurs when trying with latest wildfly upstream/master bits. 
> Server logs:
> {code:title=Server 1}
> [mvinkler at localhost jboss-eap-7.0_1]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_1
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 14:49:40,976 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 14:49:41,156 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 14:49:41,204 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 14:49:41,957 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 2) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 14:49:41,962 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment clusterbench-ee7.ear
> 14:49:41,979 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 30) WFLYDR0001: Content added at location /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/data/content/b4/8714b2fc6cba3b7ba7fac5e1100c85dc0a36ce/content
> 14:49:42,052 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 14:49:42,073 INFO  [org.xnio] (MSC service thread 1-6) XNIO version 3.4.0.Beta1
> 14:49:42,078 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.4.0.Beta1
> 14:49:42,100 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 4.0.9.Final
> 14:49:42,107 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 14:49:42,111 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 14:49:42,116 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 14:49:42,212 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 14:49:42,231 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 14:49:42,233 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 14:49:42,245 INFO  [org.jboss.as.connector] (MSC service thread 1-5) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 14:49:42,248 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 14:49:42,249 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 14:49:42,254 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 14:49:42,253 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 14:49:42,264 INFO  [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 14:49:42,310 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:42,311 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:42,339 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 14:49:42,339 INFO  [org.jboss.as.naming] (MSC service thread 1-4) WFLYNAM0003: Starting Naming Service
> 14:49:42,419 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_1/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 14:49:42,429 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
> 14:49:42,431 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0018: Host default-host starting
> 14:49:42,485 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080
> 14:49:42,487 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8009
> 14:49:42,490 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 14:49:42,511 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 14:49:42,597 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 14:49:42,641 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_1/standalone/deployments
> 14:49:42,647 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "clusterbench-ee7.ear" (runtime-name: "clusterbench-ee7.ear")
> 14:49:42,723 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 14:49:42,726 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-passivating.war")
> 14:49:42,726 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-ejb.jar")
> 14:49:42,727 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-default.war")
> 14:49:42,847 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-7) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-default.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:42,852 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:43,066 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:43,066 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:43,067 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:43,067 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:46,454 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000078: Starting JGroups channel server
> 14:49:46,464 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000094: Received new cluster view for channel server: [node1|0] (1) [node1]
> 14:49:46,467 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000079: Channel server local address is node1, physical addresses are [127.0.0.1:55200]
> 14:49:46,471 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 14:49:46,595 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started default cache from server container
> 14:49:46,625 INFO  [org.wildfly.clustering.server] (ServerService Thread Pool -- 64) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."clusterbench-ee7.ear".FIRST_MODULE_USE service
> 14:49:48,948 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,ee,node1) ISPN000094: Received new cluster view for channel server: [node1|1] (2) [node1, node2]
> 14:49:49,477 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=1, rebalanceId=1, currentCH=ReplicatedConsistentHash{ns = 60, owners = (1)[node1: 60]}, pendingCH=ReplicatedConsistentHash{ns = 60, owners = (2)[node1: 30, node2: 30]}, unionCH=null, actualMembers=[node1, node2]}
> 14:54:42,636 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]'
> 14:54:42,695 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-passivating.war) in 57ms
> 14:54:42,695 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-web-default.war) in 57ms
> 14:54:42,695 INFO  [org.infinispan.CLUSTER] (remote-thread--p2-t1) ISPN000336: Finished cluster-wide rebalance for cache default, topology id = 1
> 14:54:42,698 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0003: Stopped default cache from server container
> 14:54:42,699 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0208: Stopped subdeployment (runtime-name: clusterbench-ee7-ejb.jar) in 61ms
> 14:54:42,701 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel server
> 14:54:42,702 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel server
> 14:54:42,707 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 69ms
> 14:54:42,716 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0022: Deploy of deployment "clusterbench-ee7.ear" was rolled back with no failure message
> 14:54:42,718 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0008: Undertow HTTP listener default suspending
> 14:54:42,721 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 39) MODCLUSTER000002: Initiating mod_cluster shutdown
> 14:54:42,719 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow AJP listener ajp suspending
> 14:54:42,722 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0007: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 14:54:42,723 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 14:54:42,722 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 14:54:42,724 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> 14:54:42,728 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.0.Beta9 stopping
> 14:54:42,728 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 14:54:42,747 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 14:54:42,752 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 14:54:42,765 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 9ms
> {code}
> {code:title=Server 2}
> [mvinkler at localhost jboss-eap-7.0_2]$ ./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /usr/work/eap/tmp2/jboss-eap-7.0_2
>   JAVA: /usr/work/java/jdk1.8.0_45/bin/java
>   JAVA_OPTS:  -server -verbose:gc -Xloggc:"/usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 14:49:46,623 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 14:49:46,835 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 14:49:46,883 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 14:49:47,735 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 14:49:47,851 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 14:49:47,866 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.4.0.Beta1
> 14:49:47,874 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.4.0.Beta1
> 14:49:47,908 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.9.Final
> 14:49:47,909 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 14:49:47,916 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 14:49:47,997 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 45) WFLYCLJG0001: Activating JGroups subsystem.
> 14:49:47,999 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 14:49:48,016 INFO  [org.jboss.as.connector] (MSC service thread 1-5) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.5.Final)
> 14:49:48,024 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 14:49:48,027 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 51) WFLYNAM0001: Activating Naming Subsystem
> 14:49:48,028 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 14:49:48,034 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 14:49:48,059 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 14:49:48,079 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 58) WFLYSEC0002: Activating Security Subsystem
> 14:49:48,085 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:48,088 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0003: Undertow 1.3.0.Beta9 starting
> 14:49:48,111 INFO  [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 14:49:48,123 INFO  [org.jboss.as.naming] (MSC service thread 1-5) WFLYNAM0003: Starting Naming Service
> 14:49:48,123 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-8) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 14:49:48,188 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path '/usr/work/eap/tmp2/jboss-eap-7.0_2/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 14:49:48,191 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0012: Started server default-server.
> 14:49:48,192 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0018: Host default-host starting
> 14:49:48,236 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow AJP listener ajp listening on /127.0.0.1:8109
> 14:49:48,240 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8180
> 14:49:48,243 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 14:49:48,256 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 14:49:48,358 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 14:49:48,423 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /usr/work/eap/tmp2/jboss-eap-7.0_2/standalone/deployments
> 14:49:48,434 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "clusterbench-ee7.ear" (runtime-name: "clusterbench-ee7.ear")
> 14:49:48,515 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-passivating.war")
> 14:49:48,515 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-ejb.jar")
> 14:49:48,515 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "clusterbench-ee7-web-default.war")
> 14:49:48,530 INFO  [org.jboss.ws.common.management] (MSC service thread 1-3) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Beta1
> 14:49:48,661 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:48,664 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.clusterbench-ee7.ear.clusterbench-ee7-web-default.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
> 14:49:48,875 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:48,875 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:48,876 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 14:49:48,876 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-8) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 14:49:49,291 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000078: Starting JGroups channel server
> 14:49:49,299 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000094: Received new cluster view for channel server: [node1|1] (2) [node1, node2]
> 14:49:49,302 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 64) ISPN000079: Channel server local address is node2, physical addresses are [127.0.0.1:55300]
> 14:49:49,345 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) ISPN000128: Infinispan version: Infinispan 'Infinite Darkness' 8.0.0.CR1
> 14:50:49,523 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 64) MSC000001: Failed to start service jboss.infinispan.server.default: org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>         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.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>         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.ComponentRegistry.start(ComponentRegistry.java:218)
>         at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
>         at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
>         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: Initial state transfer timed out for cache default on node2
>         at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
>         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)
>         ... 19 more
> 14:50:49,526 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:50:49,529 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "infinispan"),
>     ("cache-container" => "server"),
>     ("replicated-cache" => "default")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.infinispan.server.default" => "org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>     Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
>     Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache default on node2"}}
> 14:50:49,557 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 14:50:49,559 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.infinispan.server.default: org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> 14:50:49,642 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:10090/management
> 14:50:49,643 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:10090
> 14:50:49,643 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) started (with errors) in 63233ms - Started 321 of 583 services (7 services failed or missing dependencies, 363 services are lazy, passive or on-demand)
> 14:51:49,528 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:52:49,529 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:53:49,531 WARN  [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p4-t2) ISPN000209: Failed to retrieve transactions for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59] of cache default from node node1: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node1
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$16/514373550.apply(Unknown Source)
>         at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>         at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>         at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>         at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>         at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         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)
> 14:54:42,713 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,ee,node2) ISPN000094: Received new cluster view for channel server: [node2|2] (1) [node2]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 09:46:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 14 Sep 2015 09:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-978) Build unnecessarily creates
 domain/data dir
In-Reply-To: <JIRA.12584713.1441984603000@Atlassian.JIRA>
References: <JIRA.12584713.1441984603000@Atlassian.JIRA>
	<JIRA.12584713.1441984603000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584713.1441984603000.26920.1442238360152@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-978:
------------------------------------
    Priority: Minor  (was: Major)


> Build unnecessarily creates domain/data dir
> -------------------------------------------
>
>                 Key: WFCORE-978
>                 URL: https://issues.jboss.org/browse/WFCORE-978
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 2.0.0.Beta7
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> The build has been creating a dir in the domain tree going all the way back to very early days when it wasn't clear there wouldn't be a "deployments" dir analogous to standalone/deployments:
> https://github.com/wildfly/wildfly-core/commit/9d2b1ac81c29b629b0426836d4dbe743e016d73f
> Since then the name of the dir has been tweaked twice as people tried to guess what the point of it was, leading via a kind of game of telephone to the build now creating domain/data/content, something completely different from any "deployments" dir used by a scanner.
> We don't precreate standalone/data/content and shouldn't need to precreate domain/data/content.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 09:46:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 14 Sep 2015 09:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-978) Build unnecessarily creates
 domain/data dir
In-Reply-To: <JIRA.12584713.1441984603000@Atlassian.JIRA>
References: <JIRA.12584713.1441984603000@Atlassian.JIRA>
	<JIRA.12584713.1441984603000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584713.1441984603000.26922.1442238360192@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-978:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1059


> Build unnecessarily creates domain/data dir
> -------------------------------------------
>
>                 Key: WFCORE-978
>                 URL: https://issues.jboss.org/browse/WFCORE-978
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 2.0.0.Beta7
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> The build has been creating a dir in the domain tree going all the way back to very early days when it wasn't clear there wouldn't be a "deployments" dir analogous to standalone/deployments:
> https://github.com/wildfly/wildfly-core/commit/9d2b1ac81c29b629b0426836d4dbe743e016d73f
> Since then the name of the dir has been tweaked twice as people tried to guess what the point of it was, leading via a kind of game of telephone to the build now creating domain/data/content, something completely different from any "deployments" dir used by a scanner.
> We don't precreate standalone/data/content and shouldn't need to precreate domain/data/content.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 09:55:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 14 Sep 2015 09:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-602) Ability to view an objects
 index of it's position in a list.
In-Reply-To: <JIRA.12566092.1426592101000@Atlassian.JIRA>
References: <JIRA.12566092.1426592101000@Atlassian.JIRA>
	<JIRA.12566092.1426592101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566092.1426592101000.26945.1442238900131@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-602:
-----------------------------------------

I recommend you convert this to a top-level issue and then resolve the parent if the main work is done. This will need dev list discussion.

> Ability to view an objects index of it's position in a list.
> ------------------------------------------------------------
>
>                 Key: WFCORE-602
>                 URL: https://issues.jboss.org/browse/WFCORE-602
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>              Labels: affects_elytron
>
> General improvements are being made to the management model for more fine grained manipulation of complex attributes, amongst these changes will be the ability to insert items at a specific position in a list.
> This feature request is to ask for the ability to see an items index to identify it's position.
> i.e. an end user can call :read-recource and see an items position without needing to count how many items there are in order to identify the position of the next insert.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 10:30:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Sep 2015 10:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5337) NPE when restarting
 Infinispan cache container service
In-Reply-To: <JIRA.12584831.1442240970000@Atlassian.JIRA>
References: <JIRA.12584831.1442240970000@Atlassian.JIRA>
	<JIRA.12584831.1442240970985@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584831.1442240970000.27165.1442241000210@Atlassian.JIRA>

Paul Ferraro created WFLY-5337:
----------------------------------

             Summary: NPE when restarting Infinispan cache container service
                 Key: WFLY-5337
                 URL: https://issues.jboss.org/browse/WFLY-5337
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
         Environment: 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.
{nobreak}
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
{nobreak}
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 10:43:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Sep 2015 10:43:00 -0400 (EDT)
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.27229.1442241780158@Atlassian.JIRA>


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

Paul Ferraro updated WFLY-5337:
-------------------------------
    Summary: NPE when restarting Infinispan transport  (was: NPE when restarting Infinispan cache container service)


> 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
>         Environment: 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.
> {nobreak}
> 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
> {nobreak}
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 10:45:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Sep 2015 10:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-288) Add authorize() or
 "changeIdentity()" method to SecurityIdentity
In-Reply-To: <JIRA.12584833.1442241852000@Atlassian.JIRA>
References: <JIRA.12584833.1442241852000@Atlassian.JIRA>
	<JIRA.12584833.1442241852737@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584833.1442241852000.27241.1442241900150@Atlassian.JIRA>

David Lloyd created ELY-288:
-------------------------------

             Summary: Add authorize() or "changeIdentity()" method to SecurityIdentity
                 Key: ELY-288
                 URL: https://issues.jboss.org/browse/ELY-288
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: API / SPI
            Reporter: David Lloyd


Add a method to SecurityIdentity which accepts a name and uses it to attempt to authorize a run-as-principal operation.  Unlike org.wildfly.security.auth.server.ServerAuthenticationContext#authorize(), this method performs the authorization in the context of an existing, established SecurityIdentity instead of creating a new one based off of an authentication.

The existing authorize() method on SAC should be refactored to reuse SecurityIdentity's authorize function once this change is made.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 10:48:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Sep 2015 10:48:00 -0400 (EDT)
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.27251.1442242080449@Atlassian.JIRA>


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

Paul Ferraro updated WFLY-5337:
-------------------------------
    Environment:     (was: 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.
{nobreak}
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
{nobreak})


> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 10:48:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Sep 2015 10:48:00 -0400 (EDT)
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.27256.1442242080686@Atlassian.JIRA>


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

Paul Ferraro updated WFLY-5337:
-------------------------------
    Description: 
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.
{nobreak}
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
{nobreak}


> 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
>
> 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.
> {nobreak}
> 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
> {nobreak}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 10:49:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Sep 2015 10:49:00 -0400 (EDT)
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.27266.1442242140377@Atlassian.JIRA>


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

Paul Ferraro updated WFLY-5337:
-------------------------------
    Description: 
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}

  was:
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.
{nobreak}
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
{nobreak}



> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 11:00:01 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Sep 2015 11:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.27321.1442242801886@Atlassian.JIRA>


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

David Lloyd reassigned ELY-282:
-------------------------------

    Assignee: David Lloyd  (was: Jan Kalina)


> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 11:12:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 14 Sep 2015 11:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.27346.1442243520106@Atlassian.JIRA>


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

Jan Kalina commented on ELY-282:
--------------------------------

What about *CredentialCallback.allowedTypes* ? Should it be ignored now? Or should it be used only for checking?

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 11:30:00 2015
From: issues at jboss.org (Erich Duda (JIRA))
Date: Mon, 14 Sep 2015 11:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5338) Lost messages in
 Publisher/Subscriber model where many subscribers are connected to a topic
In-Reply-To: <JIRA.12584851.1442244532000@Atlassian.JIRA>
References: <JIRA.12584851.1442244532000@Atlassian.JIRA>
	<JIRA.12584851.1442244532000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584851.1442244532000.27482.1442244600281@Atlassian.JIRA>


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

Erich Duda moved JBEAP-1069 to WFLY-5338:
-----------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5338  (was: JBEAP-1069)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: JMS
                           (was: JMS)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.Beta2
                           (was: 7.0.0.DR9)


> Lost messages in Publisher/Subscriber model where many subscribers are connected to a topic
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5338
>                 URL: https://issues.jboss.org/browse/WFLY-5338
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>         Environment: RHEL 7 + Oracle Java 1.8.0_40
> In Fedora 22 + OpenJDK 8 the error does not occur
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>
> If many subscribers start receive messages all at once, some of the messages get lost.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 11:48:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 14 Sep 2015 11:48:00 -0400 (EDT)
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.27553.1442245680231@Atlassian.JIRA>


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

Dmitrii Tikhomirov reassigned WFLY-5309:
----------------------------------------

    Assignee: Dmitrii Tikhomirov


> 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
>         Attachments: pom.xml, 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 11:53:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 14 Sep 2015 11:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-913) Memory leak when deleting a
 tuple from an unlinked segment
In-Reply-To: <JIRA.12584856.1442245949000@Atlassian.JIRA>
References: <JIRA.12584856.1442245949000@Atlassian.JIRA>
	<JIRA.12584856.1442245949592@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584856.1442245949000.27574.1442245980471@Atlassian.JIRA>

Mario Fusco created DROOLS-913:
----------------------------------

             Summary: Memory leak when deleting a tuple from an unlinked segment
                 Key: DROOLS-913
                 URL: https://issues.jboss.org/browse/DROOLS-913
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


When deleting an object from a session all references to the object itself and the fact handle holding it should disappear. Unfortunately, as demonstrated by the test case below, in some case the deleted fact can remain as a deleted left tuple in the memory of an unlinked segment.

{code}
    @Test
    public void testBetaMemoryLeakOnFactDelete() {
        String drl =
                "rule R1 when\n" +
                "    $a : Integer(this == 1)\n" +
                "    $b : String()\n" +
                "    $c : Integer(this == 2)\n" +
                "then \n" +
                "end\n" +
                "rule R2 when\n" +
                "    $a : Integer(this == 1)\n" +
                "    $b : String()\n" +
                "then \n" +
                "end\n";

        KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
                                             .build()
                                             .newKieSession();

        FactHandle fh1 = ksession.insert(1);
        FactHandle fh2 = ksession.insert("test");
        ksession.fireAllRules();

        ksession.delete(fh1);
        ksession.delete(fh2);
        ksession.fireAllRules();

        NodeMemories nodeMemories = ((InternalWorkingMemory) ksession).getNodeMemories();
        for (int i = 0; i < nodeMemories.length(); i++) {
            Memory memory = nodeMemories.peekNodeMemory( i );
            if ( memory != null && memory.getSegmentMemory() != null ) {
                SegmentMemory segmentMemory = memory.getSegmentMemory();
                System.out.println( memory );
                LeftTuple deleteFirst = memory.getSegmentMemory().getStagedLeftTuples().getDeleteFirst();
                System.out.println( deleteFirst );
                assertNull( deleteFirst );
            }
        }
    }
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:06:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Sep 2015 12:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.27594.1442246760209@Atlassian.JIRA>


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

David Lloyd reassigned ELY-282:
-------------------------------

    Assignee: Jan Kalina  (was: David Lloyd)


> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:06:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Sep 2015 12:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-288) Add authorize() or
 "changeIdentity()" method to SecurityIdentity
In-Reply-To: <JIRA.12584833.1442241852000@Atlassian.JIRA>
References: <JIRA.12584833.1442241852000@Atlassian.JIRA>
	<JIRA.12584833.1442241852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584833.1442241852000.27597.1442246760259@Atlassian.JIRA>


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

David Lloyd reassigned ELY-288:
-------------------------------

    Assignee: David Lloyd


> Add authorize() or "changeIdentity()" method to SecurityIdentity
> ----------------------------------------------------------------
>
>                 Key: ELY-288
>                 URL: https://issues.jboss.org/browse/ELY-288
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>
> Add a method to SecurityIdentity which accepts a name and uses it to attempt to authorize a run-as-principal operation.  Unlike org.wildfly.security.auth.server.ServerAuthenticationContext#authorize(), this method performs the authorization in the context of an existing, established SecurityIdentity instead of creating a new one based off of an authentication.
> The existing authorize() method on SAC should be refactored to reuse SecurityIdentity's authorize function once this change is made.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:06:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Sep 2015 12:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-282) Formalize multiple credential
	support
In-Reply-To: <JIRA.12583590.1441203473000@Atlassian.JIRA>
References: <JIRA.12583590.1441203473000@Atlassian.JIRA>
	<JIRA.12583590.1441203473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583590.1441203473000.27601.1442246760343@Atlassian.JIRA>


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

David Lloyd commented on ELY-282:
---------------------------------

Just for checking, I think.

> Formalize multiple credential support
> -------------------------------------
>
>                 Key: ELY-282
>                 URL: https://issues.jboss.org/browse/ELY-282
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it.  This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}.  The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience.  The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # -Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.-
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label.  Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:17:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Sep 2015 12:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-924) Factor out common code for
 management interface definitions.
In-Reply-To: <JIRA.12582790.1440672108000@Atlassian.JIRA>
References: <JIRA.12582790.1440672108000@Atlassian.JIRA>
	<JIRA.12582790.1440672108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582790.1440672108000.27638.1442247420090@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-924:
-----------------------------------------

Will need to be reworked on top of WFCORE-949

> Factor out common code for management interface definitions.
> ------------------------------------------------------------
>
>                 Key: WFCORE-924
>                 URL: https://issues.jboss.org/browse/WFCORE-924
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha1
>
>
> These interfaces started off very simple and initially their attributes were fairly distinct due to the running mode they operated in - however as more and more attributes are added there is more common code than unique code and this is tending to mean all changes are being made in duplicate - double that if a change also impacts on the native definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Sep 2015 12:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-890) Make http-upgrade a child
 element - also use a complex attribute to hold config.
In-Reply-To: <JIRA.12581836.1439988705000@Atlassian.JIRA>
References: <JIRA.12581836.1439988705000@Atlassian.JIRA>
	<JIRA.12581836.1439988705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581836.1439988705000.27641.1442247480104@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-890:
-----------------------------------------

Will need to be reworked on top of WFCORE-949

It looks like WFCORE-949 will convert the http upgrade configuration into it's own child resource. 

> Make http-upgrade a child element - also use a complex attribute to hold config.
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-890
>                 URL: https://issues.jboss.org/browse/WFCORE-890
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha1
>
>
> With the switch to Elytron there is a true distinction between referencing authentication configuration for HTTP and authentication configuration for SASL - for this reason if the HTTP management interface will need to reference the SASL configuration independently from the HTTP configuration.
> Some top lovel attributes on the http management interface can also be deprecated as the Elytron configuration already covers these e.g. server-name sasl-protocol.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Sep 2015 12:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.27647.1442247540385@Atlassian.JIRA>


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

Darran Lofthouse updated WFCORE-949:
------------------------------------
    Labels: affects_elytron  (was: )


> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: ehsavoie Hugonnet
>              Labels: affects_elytron
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:21:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 14 Sep 2015 12:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.27656.1442247660249@Atlassian.JIRA>


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

ehsavoie Hugonnet commented on WFCORE-949:
------------------------------------------

Since removing this interface may impact the JMX subsystem we need a capability to define a management endpoint .

> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: ehsavoie Hugonnet
>              Labels: affects_elytron
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 12:30:00 2015
From: issues at jboss.org (=?UTF-8?Q?Kamil_Podle=C5=A1=C3=A1k_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 12:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5339) Missing ldap/ext package in
	sun.jdk module
In-Reply-To: <JIRA.12584858.1442248145000@Atlassian.JIRA>
References: <JIRA.12584858.1442248145000@Atlassian.JIRA>
	<JIRA.12584858.1442248145281@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584858.1442248145000.27670.1442248200157@Atlassian.JIRA>

Kamil Podle??k created WFLY-5339:
------------------------------------

             Summary: Missing ldap/ext package in sun.jdk module
                 Key: WFLY-5339
                 URL: https://issues.jboss.org/browse/WFLY-5339
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 9.0.1.Final
         Environment: jdk 1.8
            Reporter: Kamil Podle??k
            Assignee: Jason Greene


sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 12:30:00 2015
From: issues at jboss.org (=?UTF-8?Q?Kamil_Podle=C5=A1=C3=A1k_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 12:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5339) Missing ldap/ext package in
	sun.jdk module
In-Reply-To: <JIRA.12584858.1442248145000@Atlassian.JIRA>
References: <JIRA.12584858.1442248145000@Atlassian.JIRA>
	<JIRA.12584858.1442248145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584858.1442248145000.27674.1442248200426@Atlassian.JIRA>


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

Kamil Podle??k updated WFLY-5339:
---------------------------------
    Description: 
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.




  was:sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.



> Missing ldap/ext package in sun.jdk module
> ------------------------------------------
>
>                 Key: WFLY-5339
>                 URL: https://issues.jboss.org/browse/WFLY-5339
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>         Environment: jdk 1.8
>            Reporter: Kamil Podle??k
>            Assignee: Jason Greene
>
> sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 12:30:00 2015
From: issues at jboss.org (=?UTF-8?Q?Kamil_Podle=C5=A1=C3=A1k_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 12:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5339) Missing ldap/ext package in
	sun.jdk module
In-Reply-To: <JIRA.12584858.1442248145000@Atlassian.JIRA>
References: <JIRA.12584858.1442248145000@Atlassian.JIRA>
	<JIRA.12584858.1442248145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584858.1442248145000.27677.1442248200605@Atlassian.JIRA>


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

Kamil Podle??k updated WFLY-5339:
---------------------------------
    Description: 
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.

{{javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.e
xt.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
... 170 more
}}




  was:
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.






> Missing ldap/ext package in sun.jdk module
> ------------------------------------------
>
>                 Key: WFLY-5339
>                 URL: https://issues.jboss.org/browse/WFLY-5339
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>         Environment: jdk 1.8
>            Reporter: Kamil Podle??k
>            Assignee: Jason Greene
>
> sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.
> {{javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.e
> xt.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
> at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
> at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
> at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
> ... 170 more
> }}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 12:31:00 2015
From: issues at jboss.org (=?UTF-8?Q?Kamil_Podle=C5=A1=C3=A1k_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 12:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5339) Missing ldap/ext package in
	sun.jdk module
In-Reply-To: <JIRA.12584858.1442248145000@Atlassian.JIRA>
References: <JIRA.12584858.1442248145000@Atlassian.JIRA>
	<JIRA.12584858.1442248145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584858.1442248145000.27679.1442248260323@Atlassian.JIRA>


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

Kamil Podle??k updated WFLY-5339:
---------------------------------
    Description: 
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.

{{javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.e
xt.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
... 170 more}}





  was:
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.

{{javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.e
xt.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
... 170 more
}}






> Missing ldap/ext package in sun.jdk module
> ------------------------------------------
>
>                 Key: WFLY-5339
>                 URL: https://issues.jboss.org/browse/WFLY-5339
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>         Environment: jdk 1.8
>            Reporter: Kamil Podle??k
>            Assignee: Jason Greene
>
> sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.
> {{javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.e
> xt.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
> at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
> at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
> at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
> ... 170 more}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 12:31:00 2015
From: issues at jboss.org (=?UTF-8?Q?Kamil_Podle=C5=A1=C3=A1k_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 12:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5339) Missing ldap/ext package in
	sun.jdk module
In-Reply-To: <JIRA.12584858.1442248145000@Atlassian.JIRA>
References: <JIRA.12584858.1442248145000@Atlassian.JIRA>
	<JIRA.12584858.1442248145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584858.1442248145000.27682.1442248260398@Atlassian.JIRA>


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

Kamil Podle??k updated WFLY-5339:
---------------------------------
    Description: 
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.

javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.ext.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
... 170 more





  was:
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.

{{javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.e
xt.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
... 170 more}}







> Missing ldap/ext package in sun.jdk module
> ------------------------------------------
>
>                 Key: WFLY-5339
>                 URL: https://issues.jboss.org/browse/WFLY-5339
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>         Environment: jdk 1.8
>            Reporter: Kamil Podle??k
>            Assignee: Jason Greene
>
> sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.
> javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.ext.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
> at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
> at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
> at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
> ... 170 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 12:32:00 2015
From: issues at jboss.org (=?UTF-8?Q?Kamil_Podle=C5=A1=C3=A1k_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 12:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5339) Missing ldap/ext package in
	sun.jdk module
In-Reply-To: <JIRA.12584858.1442248145000@Atlassian.JIRA>
References: <JIRA.12584858.1442248145000@Atlassian.JIRA>
	<JIRA.12584858.1442248145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584858.1442248145000.27689.1442248320122@Atlassian.JIRA>


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

Kamil Podle??k updated WFLY-5339:
---------------------------------
    Description: 
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.

{noformat}
javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.ext.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
... 170 more
{noformat}




  was:
sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.

javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.ext.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
... 170 more







> Missing ldap/ext package in sun.jdk module
> ------------------------------------------
>
>                 Key: WFLY-5339
>                 URL: https://issues.jboss.org/browse/WFLY-5339
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>         Environment: jdk 1.8
>            Reporter: Kamil Podle??k
>            Assignee: Jason Greene
>
> sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.
> {noformat}
> javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.ext.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
> at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
> at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
> at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
> ... 170 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 12:32:00 2015
From: issues at jboss.org (=?UTF-8?Q?Kamil_Podle=C5=A1=C3=A1k_=28JIRA=29?=)
Date: Mon, 14 Sep 2015 12:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5339) Missing ldap/ext package in
	sun.jdk module
In-Reply-To: <JIRA.12584858.1442248145000@Atlassian.JIRA>
References: <JIRA.12584858.1442248145000@Atlassian.JIRA>
	<JIRA.12584858.1442248145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584858.1442248145000.27693.1442248320179@Atlassian.JIRA>


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

Kamil Podle??k updated WFLY-5339:
---------------------------------
    Steps to Reproduce: 
Run example code from http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html
(http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/src/StartTls.java) inside ear deployed to wildfly server.  The line
{{StartTlsResponse tls = (StartTlsResponse) ctx.extendedOperation(new StartTlsRequest());}}
throws the exception from main description.

I don't have proper test case prepared and published, hopefully the example above is sufficient.


  was:
Run example code from http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html
(http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/src/StartTls.java) inside ear deployed to wildfly server.  The line
{{StartTlsResponse tls = (StartTlsResponse) ctx.extendedOperation(new StartTlsRequest());}}
throws exception:
{{
javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.e
xt.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
        at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
        at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
        at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
        at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
        at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
        at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
        ... 170 more
}}

I don't have proper test case prepared and published, hopefully the example above is sufficient.




> Missing ldap/ext package in sun.jdk module
> ------------------------------------------
>
>                 Key: WFLY-5339
>                 URL: https://issues.jboss.org/browse/WFLY-5339
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>         Environment: jdk 1.8
>            Reporter: Kamil Podle??k
>            Assignee: Jason Greene
>
> sun.jdk module already contains package com.sun.jndi.ldap  needed to access LDAP servers via jndi (AS7-1500), but it com.sun.jndi.ldap.ext is missing. This means that Start TLS does not work as documented (http://docs.oracle.com/javase/jndi/tutorial/ldap/ext/starttls.html), failing with ClassNotFoundException.
> {noformat}
> javax.naming.ConfigurationException: Cannot load implementation of javax.naming.ldap.StartTlsResponse [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.ext.StartTlsResponseImpl from [Module "deployment.xxx.ear.xxx.jar:main" from Service Module Loader]]
> at javax.naming.ldap.StartTlsRequest.wrapException(StartTlsRequest.java:218)
> at javax.naming.ldap.StartTlsRequest.createExtendedResponse(StartTlsRequest.java:207)
> at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3269)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:184)
> at ch.ips.g2.b.core.adp.mailbox.external.LdapExecutor.executeOperation(LdapExecutor.java:115)
> ... 170 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 12:59:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Sep 2015 12:59:00 -0400 (EDT)
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.1442249900052@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584861.1442249900000.27717.1442249940179@Atlassian.JIRA>

Darran Lofthouse created WFLY-5340:
--------------------------------------

             Summary: 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.CR2


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 references 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
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 13:01:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Sep 2015 13:01:01 -0400 (EDT)
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.27720.1442250061562@Atlassian.JIRA>


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

Darran Lofthouse updated WFLY-5340:
-----------------------------------
    Description: 
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.

  was:
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 references 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.



> 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.CR2
>
>
> 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
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 14:03:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 14 Sep 2015 14:03:00 -0400 (EDT)
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.27853.1442253780097@Atlassian.JIRA>


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

Dmitrii Tikhomirov commented on WFLY-5309:
------------------------------------------

You should try RichFaces 4.5.8.Final. Please put it in your pom.xml

		<dependency>
			<groupId>org.richfaces</groupId>
			<artifactId>richfaces-core</artifactId>
			<version>4.5.8.Final</version>
		</dependency>
... and build again.


> 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
>         Attachments: pom.xml, 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 14:08:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 14 Sep 2015 14:08:00 -0400 (EDT)
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.27876.1442254080422@Atlassian.JIRA>


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

Dmitrii Tikhomirov updated WFLY-5309:
-------------------------------------
    Attachment: wildfly-test-RF-4.5.8.tar.gz


example updated to 4.5.8 version of RichFaces

> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 14:10:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 14 Sep 2015 14:10:00 -0400 (EDT)
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.27884.1442254200238@Atlassian.JIRA>


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

Dmitrii Tikhomirov resolved WFLY-5309.
--------------------------------------
    Resolution: Done


> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 14:11:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 14 Sep 2015 14:11:00 -0400 (EDT)
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.27887.1442254260118@Atlassian.JIRA>


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

Dmitrii Tikhomirov edited comment on WFLY-5309 at 9/14/15 2:10 PM:
-------------------------------------------------------------------

You should use RichFaces 4.5.8.Final. Please put it in your pom.xml

		<dependency>
			<groupId>org.richfaces</groupId>
			<artifactId>richfaces-core</artifactId>
			<version>4.5.8.Final</version>
		</dependency>
... and build again.



was (Author: treblereel):
You should try RichFaces 4.5.8.Final. Please put it in your pom.xml

		<dependency>
			<groupId>org.richfaces</groupId>
			<artifactId>richfaces-core</artifactId>
			<version>4.5.8.Final</version>
		</dependency>
... and build again.


> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 15:03:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Sep 2015 15:03:00 -0400 (EDT)
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.27931.1442257380087@Atlassian.JIRA>


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

Darran Lofthouse commented on WFLY-5340:
----------------------------------------

Following on we also need to ensure the correct module is used when PolicyConfigurationFactory is called - for this reason it makes sense to add a new WildFly specific system property to specify the module to use for JACC initialisation that will cover the BootstrapService and JaccService.

> 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.CR2
>
>
> 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
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 14 15:37:00 2015
From: issues at jboss.org (Larry O'Leary (JIRA))
Date: Mon, 14 Sep 2015 15:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
In-Reply-To: <JIRA.12562785.1423556555000@Atlassian.JIRA>
References: <JIRA.12562785.1423556555000@Atlassian.JIRA>
	<JIRA.12562785.1423556555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562785.1423556555000.28034.1442259420946@Atlassian.JIRA>


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

Larry O'Leary commented on REMJMX-94:
-------------------------------------

[~dlofthouse] any update on this? Did we ever hear back from [~dmlloyd]?

> Memory leak in remoting-jmx
> ---------------------------
>
>                 Key: REMJMX-94
>                 URL: https://issues.jboss.org/browse/REMJMX-94
>             Project: Remoting JMX
>          Issue Type: Bug
>    Affects Versions: 1.1.3.Final
>            Reporter: Libor Zoubek
>            Assignee: Darran Lofthouse
>              Labels: memory_leak
>             Fix For: 2.0.2.CR1
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org/jboss/remotingjmx/memleak/test/Main.java
> I am not sure if memleak is in remoting-jmx or some other underlying stuff. 
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 16:05:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Sep 2015 16:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-289) RealmIdentity.getName() is
	useless
In-Reply-To: <JIRA.12584882.1442261040000@Atlassian.JIRA>
References: <JIRA.12584882.1442261040000@Atlassian.JIRA>
	<JIRA.12584882.1442261040417@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584882.1442261040000.28121.1442261100078@Atlassian.JIRA>

David Lloyd created ELY-289:
-------------------------------

             Summary: RealmIdentity.getName() is useless
                 Key: ELY-289
                 URL: https://issues.jboss.org/browse/ELY-289
             Project: WildFly Elytron
          Issue Type: Task
          Components: API / SPI
            Reporter: David Lloyd
            Assignee: David Lloyd


The getName() method on RealmIdentity is useless, but prevents the creation of singleton instances which can act for multiple identities.

Remove it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 17:55:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Sep 2015 17:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
In-Reply-To: <JIRA.12562785.1423556555000@Atlassian.JIRA>
References: <JIRA.12562785.1423556555000@Atlassian.JIRA>
	<JIRA.12562785.1423556555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562785.1423556555000.28272.1442267700269@Atlassian.JIRA>


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

David Lloyd commented on REMJMX-94:
-----------------------------------

Ideally XNIO should be factored out into a shared library that isn't destroyed and re-instantiated repeatedly.  This cleanup is meant to be global to the JVM; there really isn't a reasonable fix for this that I can imagine.

> Memory leak in remoting-jmx
> ---------------------------
>
>                 Key: REMJMX-94
>                 URL: https://issues.jboss.org/browse/REMJMX-94
>             Project: Remoting JMX
>          Issue Type: Bug
>    Affects Versions: 1.1.3.Final
>            Reporter: Libor Zoubek
>            Assignee: Darran Lofthouse
>              Labels: memory_leak
>             Fix For: 2.0.2.CR1
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org/jboss/remotingjmx/memleak/test/Main.java
> I am not sure if memleak is in remoting-jmx or some other underlying stuff. 
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 21:34:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 14 Sep 2015 21:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5310) WARN HttpContextLifecycle
 guard leak detected. The Servlet container is not fully compliant during
 application deployment
In-Reply-To: <JIRA.12584416.1441808910000@Atlassian.JIRA>
References: <JIRA.12584416.1441808910000@Atlassian.JIRA>
	<JIRA.12584416.1441808910000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584416.1441808910000.28434.1442280840127@Atlassian.JIRA>


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

Stuart Douglas commented on WFLY-5310:
--------------------------------------

This is a problematic one. Basically when Undertow is told to shutdown it will destroy the CDI listener, this means that if there are any active requests that finish after this has happened the requestDestroyed listener will not be invoked. 

The simple solution to this is to use graceful shutdown, so the requests are allowed to finish before the listener is destroyed. I don't think there is much that can be done about this otherwise, this problem is just one of many that can occur if the deployment is stopped while requests are active.

> WARN HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant during application deployment
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5310
>                 URL: https://issues.jboss.org/browse/WFLY-5310
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> 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-async (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with asynchronously replicated cache)
> During application re-deployment (after previous undeployment) on any of the nodes, this WARN message is being logged approx. 60 times - stacktrace:
> {code}
> [JBossINF] [0m[0m19:07:15,617 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 2015/08/28 19:07:15:621 EDT [DEBUG][RMI TCP Connection(16)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Got result: {"outcome" : "success"}
> [JBossINF] [0m[0m19:07:20,563 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0033: Deployment clusterbench-ee7.ear was previously undeployed by this scanner but has been redeployed by another management tool. Marker file /tmp/hudson/jboss-eap-7.0/standalone/deployments/clusterbench-ee7.ear.undeployed is being removed to record this fact.
> [JBossINF] [0m[33m19:08:01,353 WARN  [org.jboss.weld.Servlet] (default task-2) WELD-000714: HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant. The value was 1
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-undeploy-repl-async/6/console-perf18/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 21:35:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 14 Sep 2015 21:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5310) WARN HttpContextLifecycle
 guard leak detected. The Servlet container is not fully compliant during
 application deployment
In-Reply-To: <JIRA.12584416.1441808910000@Atlassian.JIRA>
References: <JIRA.12584416.1441808910000@Atlassian.JIRA>
	<JIRA.12584416.1441808910000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584416.1441808910000.28437.1442280900147@Atlassian.JIRA>


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

Stuart Douglas resolved WFLY-5310.
----------------------------------
    Resolution: Rejected


> WARN HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant during application deployment
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5310
>                 URL: https://issues.jboss.org/browse/WFLY-5310
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> 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-async (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with asynchronously replicated cache)
> During application re-deployment (after previous undeployment) on any of the nodes, this WARN message is being logged approx. 60 times - stacktrace:
> {code}
> [JBossINF] [0m[0m19:07:15,617 INFO  [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 2015/08/28 19:07:15:621 EDT [DEBUG][RMI TCP Connection(16)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Got result: {"outcome" : "success"}
> [JBossINF] [0m[0m19:07:20,563 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0033: Deployment clusterbench-ee7.ear was previously undeployed by this scanner but has been redeployed by another management tool. Marker file /tmp/hudson/jboss-eap-7.0/standalone/deployments/clusterbench-ee7.ear.undeployed is being removed to record this fact.
> [JBossINF] [0m[33m19:08:01,353 WARN  [org.jboss.weld.Servlet] (default task-2) WELD-000714: HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant. The value was 1
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-undeploy-repl-async/6/console-perf18/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 14 21:44:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 14 Sep 2015 21:44:00 -0400 (EDT)
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.28443.1442281440993@Atlassian.JIRA>


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

Stuart Douglas resolved WFLY-4696.
----------------------------------
    Fix Version/s: 10.0.0.CR1
                       (was: 9.0.0.CR2)
                       (was: 10.0.0.Alpha3)
       Resolution: Done


Resolving due to inactivity. The XNIO patch fixes a bug which could cause this error, which will be in Wildfly 10.0.0.CR1

> 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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 02:00:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 15 Sep 2015 02:00:00 -0400 (EDT)
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.1442296753923@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584902.1442296753000.28476.1442296800075@Atlassian.JIRA>

Stuart Douglas created WFLY-5341:
------------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 02:51:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 15 Sep 2015 02:51:00 -0400 (EDT)
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.1442299840829@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584903.1442299840000.28505.1442299860516@Atlassian.JIRA>

Jeff Mesnil created WFLY-5342:
---------------------------------

             Summary: 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 03:41:00 2015
From: issues at jboss.org (Pavan Sharma (JIRA))
Date: Tue, 15 Sep 2015 03:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBFORUMS-308) spring bean setter is not
 working in jboss. Injected bean is getting null while invoking
In-Reply-To: <JIRA.12584907.1442302820000@Atlassian.JIRA>
References: <JIRA.12584907.1442302820000@Atlassian.JIRA>
	<JIRA.12584907.1442302820710@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584907.1442302820000.28572.1442302860201@Atlassian.JIRA>

Pavan Sharma created JBFORUMS-308:
-------------------------------------

             Summary: spring bean setter is not working in jboss. Injected bean is getting null while invoking
                 Key: JBFORUMS-308
                 URL: https://issues.jboss.org/browse/JBFORUMS-308
             Project: JBoss Forums
          Issue Type: Bug
          Components: Integration
            Reporter: Pavan Sharma
            Assignee: Luca Stancapiano


I am getting one class instance while not for other in same class and defined in same config.xml file. This is working fine when deployed on webSphere & Tomcat but creating issue on Jboss EAP 6.3.

1. I have one auth.xml config file that contains below 

<bean id="loginController" class="com.abc.mvc.controller.auth.LoginController"
		parent="abcAbstractCommandController">
		<property name="spAuthOperation" ref="spAuthOperation" />
		<property name="commandName" value="loginCommand" />
		<property name="commandClass"
			value="com.abc.mvc.command.auth.LoginCommand" />
		<property name="validator" ref="loginValidator" />
		<property name="otpAuthJSONBldr" ref="otpAuthJSONBldr" />
	</bean>

<bean id="otpAuthJSONBldr"
		class="com.abc.json.builder.auth.OTPAuthJSONBldr"
		parent="comJSONBuilder" />

2. LoginController.java; In this class i have injected one operation and one jsonBldr that is defined in auth.xml config file.

public class LoginController extends AbstractCommandController {

	SPAuthOperation spAuthOperation;
	
        private ABCJSONBuilder otpAuthJSONBldr;
	

       public SPAuthOperation  getspAuthOperation() {
		return spAuthOperation;
	}

	public void setspAuthOperation(SPAuthOperation  spAuthOperation) {
		this.spAuthOperation = spAuthOperation

	}

	public ABCJSONBuilder getOtpAuthJSONBldr() {
		return otpAuthJSONBldr;
	}

	public void setOtpAuthJSONBldr(ABCJSONBuilder otpAuthJSONBldr1) {
		this.otpAuthJSONBldr = otpAuthJSONBldr1;

	}

}

now when i am trying to invoke logincontroller thru my application then getting spAuthOperation class instance but not otpAuthJSONBldr. this is strange thing.

Below is the Jboss trace log where also getting 'otpJsonBldr' instance created on server startup but then not getting at runtime and application invocation..

2015-09-14 12:38:17,656 [ServerService Thread Pool -- 59] TRACE - Found bean property 'otpAuthJSONBldr' of type [com.abc.json.builder.auth.ABCJSONBuilder]
{color:red}Creating shared instance of singleton bean 'otpAuthJSONBldr'{color}
2015-09-14 12:38:21,833 [ServerService Thread Pool -- 59] DEBUG - Creating instance of bean 'otpAuthJSONBldr'
2015-09-14 12:38:21,834 [ServerService Thread Pool -- 59] DEBUG - Eagerly caching bean 'otpAuthJSONBldr' to allow for resolving potential circular references
2015-09-14 12:38:21,835 [ServerService Thread Pool -- 59] TRACE - Getting BeanInfo for class [com.abc.json.builder.auth.otpAuthJSONBldr]
2015-09-14 12:38:21,837 [ServerService Thread Pool -- 59] TRACE - Caching PropertyDescriptors for class [com.abc.json.builder.authotpAuthJSONBldr]
-----
Creating implicit proxy for bean 'otpAuthJSONBldr' with 1 common interceptors and 0 specific interceptors
2015-09-14 12:38:21,863 [ServerService Thread Pool -- 59] DEBUG - Creating CGLIB2 proxy:{color:red} target source is SingletonTargetSource for target object [com.abc.json.builder.auth.otpAuthJSONBldr at 10b53e6]{color}
2015-09-14 12:38:21,863 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: protected com.abc.json.builder.auth.ABCPayloadHeader com.abc.json.builder.authotpAuthJSONBldr.createHeader(com.abc.json.builder.auth.context.ResponseContext)
2015-09-14 12:38:21,864 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: public java.lang.Object com.abc.json.builder.auth.otpAuthJSONBldr.createJSONResponse(com.abc.json.builder.auth.context.ResponseContext)
2015-09-14 12:38:21,864 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: protected void com.abc.json.builder.auth.otpAuthJSONBldr.populatePayLoad

2015-09-14 12:38:21,882 [ServerService Thread Pool -- 59] DEBUG -{color:red} Finished creating instance of bean 'otpAuthJSONBldr'{color}


Need input on urgent basis.....

Thanks In advance



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 04:20:00 2015
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 15 Sep 2015 04:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5338) Lost messages in
 Publisher/Subscriber model where many subscribers are connected to a topic
In-Reply-To: <JIRA.12584851.1442244532000@Atlassian.JIRA>
References: <JIRA.12584851.1442244532000@Atlassian.JIRA>
	<JIRA.12584851.1442244532000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584851.1442244532000.28720.1442305200246@Atlassian.JIRA>


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

Erich Duda deleted WFLY-5338:
-----------------------------


> Lost messages in Publisher/Subscriber model where many subscribers are connected to a topic
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5338
>                 URL: https://issues.jboss.org/browse/WFLY-5338
>             Project: WildFly
>          Issue Type: Bug
>         Environment: RHEL 7 + Oracle Java 1.8.0_40
> In Fedora 22 + OpenJDK 8 the error does not occur
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>
> If many subscribers start receive messages all at once, some of the messages get lost.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 06:08:00 2015
From: issues at jboss.org (=?UTF-8?Q?Jan_Ka=C5=A1=C3=ADk_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5343) Datasource configuration
 allows editing driver name to non-existing one
In-Reply-To: <JIRA.12582670.1440592792000@Atlassian.JIRA>
References: <JIRA.12582670.1440592792000@Atlassian.JIRA>
	<JIRA.12582670.1440592792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582670.1440592792000.29146.1442311680509@Atlassian.JIRA>


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

Jan Ka??k moved HAL-816 to WFLY-5343:
-------------------------------------

              Project: WildFly  (was: HAL)
                  Key: WFLY-5343  (was: HAL-816)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
          Component/s: JCA
                           (was: Subsystem Configuration)
    Affects Version/s:     (was: 2.8.x)


> Datasource configuration allows editing driver name to non-existing one
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5343
>                 URL: https://issues.jboss.org/browse/WFLY-5343
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Jan Ka??k
>            Assignee: Bartosz Baranowski
>
> When editing datasource attributes, JDBC driver name can be changed to driver which is not installed (deployed) without any error message being showed. Although error message "A driver needs to be specified or chosen!" is showed if driver, which is not present in system, is filled in form during addition of new datasource.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:09:00 2015
From: issues at jboss.org (=?UTF-8?Q?Jan_Ka=C5=A1=C3=ADk_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5343) Datasource configuration
 allows editing driver name to non-existing one
In-Reply-To: <JIRA.12582670.1440592792000@Atlassian.JIRA>
References: <JIRA.12582670.1440592792000@Atlassian.JIRA>
	<JIRA.12582670.1440592792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582670.1440592792000.29159.1442311740331@Atlassian.JIRA>


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

Jan Ka??k reopened WFLY-5343:
-----------------------------


Based on the last comment, I moved this issue to WFLY.

> Datasource configuration allows editing driver name to non-existing one
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5343
>                 URL: https://issues.jboss.org/browse/WFLY-5343
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Jan Ka??k
>            Assignee: Bartosz Baranowski
>
> When editing datasource attributes, JDBC driver name can be changed to driver which is not installed (deployed) without any error message being showed. Although error message "A driver needs to be specified or chosen!" is showed if driver, which is not present in system, is filled in form during addition of new datasource.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:15:00 2015
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 15 Sep 2015 06:15:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5344) Datasource configuration
 allows editing driver name to non-existing one
In-Reply-To: <JIRA.12584930.1442312088000@Atlassian.JIRA>
References: <JIRA.12584930.1442312088000@Atlassian.JIRA>
	<JIRA.12584930.1442312088040@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584930.1442312088000.29212.1442312100143@Atlassian.JIRA>

Bartosz Baranowski created WFLY-5344:
----------------------------------------

             Summary: Datasource configuration allows editing driver name to non-existing one
                 Key: WFLY-5344
                 URL: https://issues.jboss.org/browse/WFLY-5344
             Project: WildFly
          Issue Type: Bug
          Components: JCA
    Affects Versions: 10.0.0.Beta2
            Reporter: Bartosz Baranowski
            Assignee: Jesper Pedersen


DataSource.driver-name can be set to anything.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 06:18:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5345) Remote client EJB IIOP lookup
 fails when wfly context factory lookup is used
In-Reply-To: <JIRA.12584932.1442312279000@Atlassian.JIRA>
References: <JIRA.12584932.1442312279000@Atlassian.JIRA>
	<JIRA.12584932.1442312279631@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584932.1442312279000.29224.1442312280163@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5345:
--------------------------------------

             Summary: Remote client EJB IIOP lookup fails when wfly context factory lookup is used
                 Key: WFLY-5345
                 URL: https://issues.jboss.org/browse/WFLY-5345
             Project: WildFly
          Issue Type: Bug
            Reporter: Ond?ej Chaloupka
            Assignee: Jason Greene
            Priority: Critical


I'm not 100% sure that this is a bug as there could be some misconfiguration from my side. Plus I do not know if wildfly-iiop-openjdk is expected to be used on client side.

When I try to use ejb lookup from client side with usage of IIOP
{code}
        System.setProperty("com.sun.CORBA.ORBUseDynamicStub", "true");

        final Properties prope = new Properties();
        prope.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory");
        prope.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.iiop.naming:org.jboss.naming.client");
        prope.put(Context.PROVIDER_URL, "corbaloc::" + serverName +":3528/JBoss/Naming/root");
        final InitialContext context = new InitialContext(prope);
        final Object ejbHome = context.lookup(beanClass.getSimpleName());

        return homeClass.cast(PortableRemoteObject.narrow(ejbHome, homeClass));
{code}

I get exception
{code}
java.lang.NullPointerException: null
 at org.wildfly.iiop.openjdk.service.CorbaORBService.getCurrent(CorbaORBService.java:222)
 at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:227)
 at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
 at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
 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.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:90)
{code}

If I use the context factory class from my local java 8 oracle jdk/open jdk {{com.sun.jndi.cosnaming.CNCtxFactory}} then it works fine.

I can see that the {{NullPointerException}} is thrown from here
https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/service/CorbaORBService.java#L277
which pointing me to suspicion that the iiop library expects a WFLY running to get service registry. But it is not available on client side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:20:01 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5345) Remote client EJB IIOP lookup
 fails when wfly context factory lookup is used
In-Reply-To: <JIRA.12584932.1442312279000@Atlassian.JIRA>
References: <JIRA.12584932.1442312279000@Atlassian.JIRA>
	<JIRA.12584932.1442312279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584932.1442312279000.29250.1442312401038@Atlassian.JIRA>


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

Ond?ej Chaloupka reassigned WFLY-5345:
--------------------------------------

    Assignee: Tomasz Adamski  (was: Jason Greene)


> Remote client EJB IIOP lookup fails when wfly context factory lookup is used
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5345
>                 URL: https://issues.jboss.org/browse/WFLY-5345
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> I'm not 100% sure that this is a bug as there could be some misconfiguration from my side. Plus I do not know if wildfly-iiop-openjdk is expected to be used on client side.
> When I try to use ejb lookup from client side with usage of IIOP
> {code}
>         System.setProperty("com.sun.CORBA.ORBUseDynamicStub", "true");
>         final Properties prope = new Properties();
>         prope.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory");
>         prope.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.iiop.naming:org.jboss.naming.client");
>         prope.put(Context.PROVIDER_URL, "corbaloc::" + serverName +":3528/JBoss/Naming/root");
>         final InitialContext context = new InitialContext(prope);
>         final Object ejbHome = context.lookup(beanClass.getSimpleName());
>         return homeClass.cast(PortableRemoteObject.narrow(ejbHome, homeClass));
> {code}
> I get exception
> {code}
> java.lang.NullPointerException: null
>  at org.wildfly.iiop.openjdk.service.CorbaORBService.getCurrent(CorbaORBService.java:222)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:227)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
>  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.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:90)
> {code}
> If I use the context factory class from my local java 8 oracle jdk/open jdk {{com.sun.jndi.cosnaming.CNCtxFactory}} then it works fine.
> I can see that the {{NullPointerException}} is thrown from here
> https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/service/CorbaORBService.java#L277
> which pointing me to suspicion that the iiop library expects a WFLY running to get service registry. But it is not available on client side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:21:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5345) Remote client EJB IIOP lookup
 fails when wfly context factory lookup is used
In-Reply-To: <JIRA.12584932.1442312279000@Atlassian.JIRA>
References: <JIRA.12584932.1442312279000@Atlassian.JIRA>
	<JIRA.12584932.1442312279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584932.1442312279000.29252.1442312460201@Atlassian.JIRA>


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

Ond?ej Chaloupka updated WFLY-5345:
-----------------------------------
    Affects Version/s: 10.0.0.Beta1


> Remote client EJB IIOP lookup fails when wfly context factory lookup is used
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5345
>                 URL: https://issues.jboss.org/browse/WFLY-5345
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> I'm not 100% sure that this is a bug as there could be some misconfiguration from my side. Plus I do not know if wildfly-iiop-openjdk is expected to be used on client side.
> When I try to use ejb lookup from client side with usage of IIOP
> {code}
>         System.setProperty("com.sun.CORBA.ORBUseDynamicStub", "true");
>         final Properties prope = new Properties();
>         prope.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory");
>         prope.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.iiop.naming:org.jboss.naming.client");
>         prope.put(Context.PROVIDER_URL, "corbaloc::" + serverName +":3528/JBoss/Naming/root");
>         final InitialContext context = new InitialContext(prope);
>         final Object ejbHome = context.lookup(beanClass.getSimpleName());
>         return homeClass.cast(PortableRemoteObject.narrow(ejbHome, homeClass));
> {code}
> I get exception
> {code}
> java.lang.NullPointerException: null
>  at org.wildfly.iiop.openjdk.service.CorbaORBService.getCurrent(CorbaORBService.java:222)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:227)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
>  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.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:90)
> {code}
> If I use the context factory class from my local java 8 oracle jdk/open jdk {{com.sun.jndi.cosnaming.CNCtxFactory}} then it works fine.
> I can see that the {{NullPointerException}} is thrown from here
> https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/service/CorbaORBService.java#L277
> which pointing me to suspicion that the iiop library expects a WFLY running to get service registry. But it is not available on client side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:21:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5345) Remote client EJB IIOP lookup
 fails when wfly context factory lookup is used
In-Reply-To: <JIRA.12584932.1442312279000@Atlassian.JIRA>
References: <JIRA.12584932.1442312279000@Atlassian.JIRA>
	<JIRA.12584932.1442312279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584932.1442312279000.29255.1442312460404@Atlassian.JIRA>


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

Ond?ej Chaloupka updated WFLY-5345:
-----------------------------------
    Component/s: IIOP


> Remote client EJB IIOP lookup fails when wfly context factory lookup is used
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5345
>                 URL: https://issues.jboss.org/browse/WFLY-5345
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> I'm not 100% sure that this is a bug as there could be some misconfiguration from my side. Plus I do not know if wildfly-iiop-openjdk is expected to be used on client side.
> When I try to use ejb lookup from client side with usage of IIOP
> {code}
>         System.setProperty("com.sun.CORBA.ORBUseDynamicStub", "true");
>         final Properties prope = new Properties();
>         prope.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory");
>         prope.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.iiop.naming:org.jboss.naming.client");
>         prope.put(Context.PROVIDER_URL, "corbaloc::" + serverName +":3528/JBoss/Naming/root");
>         final InitialContext context = new InitialContext(prope);
>         final Object ejbHome = context.lookup(beanClass.getSimpleName());
>         return homeClass.cast(PortableRemoteObject.narrow(ejbHome, homeClass));
> {code}
> I get exception
> {code}
> java.lang.NullPointerException: null
>  at org.wildfly.iiop.openjdk.service.CorbaORBService.getCurrent(CorbaORBService.java:222)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:227)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
>  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.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:90)
> {code}
> If I use the context factory class from my local java 8 oracle jdk/open jdk {{com.sun.jndi.cosnaming.CNCtxFactory}} then it works fine.
> I can see that the {{NullPointerException}} is thrown from here
> https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/service/CorbaORBService.java#L277
> which pointing me to suspicion that the iiop library expects a WFLY running to get service registry. But it is not available on client side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:23:00 2015
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 15 Sep 2015 06:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5344) Datasource configuration
 allows editing driver name to non-existing one
In-Reply-To: <JIRA.12584930.1442312088000@Atlassian.JIRA>
References: <JIRA.12584930.1442312088000@Atlassian.JIRA>
	<JIRA.12584930.1442312088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584930.1442312088000.29278.1442312580297@Atlassian.JIRA>


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

Bartosz Baranowski reassigned WFLY-5344:
----------------------------------------

    Assignee: Bartosz Baranowski  (was: Jesper Pedersen)


> Datasource configuration allows editing driver name to non-existing one
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5344
>                 URL: https://issues.jboss.org/browse/WFLY-5344
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> DataSource.driver-name can be set to anything.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 06:23:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5345) Remote client EJB IIOP lookup
 fails when wfly context factory lookup is used
In-Reply-To: <JIRA.12584932.1442312279000@Atlassian.JIRA>
References: <JIRA.12584932.1442312279000@Atlassian.JIRA>
	<JIRA.12584932.1442312279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584932.1442312279000.29281.1442312580359@Atlassian.JIRA>


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

Ond?ej Chaloupka updated WFLY-5345:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2
                           (was: 10.0.0.Beta1)


> Remote client EJB IIOP lookup fails when wfly context factory lookup is used
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5345
>                 URL: https://issues.jboss.org/browse/WFLY-5345
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> I'm not 100% sure that this is a bug as there could be some misconfiguration from my side. Plus I do not know if wildfly-iiop-openjdk is expected to be used on client side.
> When I try to use ejb lookup from client side with usage of IIOP
> {code}
>         System.setProperty("com.sun.CORBA.ORBUseDynamicStub", "true");
>         final Properties prope = new Properties();
>         prope.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory");
>         prope.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.iiop.naming:org.jboss.naming.client");
>         prope.put(Context.PROVIDER_URL, "corbaloc::" + serverName +":3528/JBoss/Naming/root");
>         final InitialContext context = new InitialContext(prope);
>         final Object ejbHome = context.lookup(beanClass.getSimpleName());
>         return homeClass.cast(PortableRemoteObject.narrow(ejbHome, homeClass));
> {code}
> I get exception
> {code}
> java.lang.NullPointerException: null
>  at org.wildfly.iiop.openjdk.service.CorbaORBService.getCurrent(CorbaORBService.java:222)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:227)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
>  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.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:90)
> {code}
> If I use the context factory class from my local java 8 oracle jdk/open jdk {{com.sun.jndi.cosnaming.CNCtxFactory}} then it works fine.
> I can see that the {{NullPointerException}} is thrown from here
> https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/service/CorbaORBService.java#L277
> which pointing me to suspicion that the iiop library expects a WFLY running to get service registry. But it is not available on client side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:24:00 2015
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 15 Sep 2015 06:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5344) Datasource configuration
 allows editing driver name to non-existing one
In-Reply-To: <JIRA.12584930.1442312088000@Atlassian.JIRA>
References: <JIRA.12584930.1442312088000@Atlassian.JIRA>
	<JIRA.12584930.1442312088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584930.1442312088000.29292.1442312640136@Atlassian.JIRA>


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

Bartosz Baranowski resolved WFLY-5344.
--------------------------------------
    Resolution: Duplicate Issue


> Datasource configuration allows editing driver name to non-existing one
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5344
>                 URL: https://issues.jboss.org/browse/WFLY-5344
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> DataSource.driver-name can be set to anything.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 06:28:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Tue, 15 Sep 2015 06:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5345) Remote client EJB IIOP lookup
 fails when wfly context factory lookup is used
In-Reply-To: <JIRA.12584932.1442312279000@Atlassian.JIRA>
References: <JIRA.12584932.1442312279000@Atlassian.JIRA>
	<JIRA.12584932.1442312279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584932.1442312279000.29297.1442312880130@Atlassian.JIRA>


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

Ond?ej Chaloupka commented on WFLY-5345:
----------------------------------------

Suggestion for reproducer contained at JBEAP-1071

> Remote client EJB IIOP lookup fails when wfly context factory lookup is used
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5345
>                 URL: https://issues.jboss.org/browse/WFLY-5345
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> I'm not 100% sure that this is a bug as there could be some misconfiguration from my side. Plus I do not know if wildfly-iiop-openjdk is expected to be used on client side.
> When I try to use ejb lookup from client side with usage of IIOP
> {code}
>         System.setProperty("com.sun.CORBA.ORBUseDynamicStub", "true");
>         final Properties prope = new Properties();
>         prope.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory");
>         prope.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.iiop.naming:org.jboss.naming.client");
>         prope.put(Context.PROVIDER_URL, "corbaloc::" + serverName +":3528/JBoss/Naming/root");
>         final InitialContext context = new InitialContext(prope);
>         final Object ejbHome = context.lookup(beanClass.getSimpleName());
>         return homeClass.cast(PortableRemoteObject.narrow(ejbHome, homeClass));
> {code}
> I get exception
> {code}
> java.lang.NullPointerException: null
>  at org.wildfly.iiop.openjdk.service.CorbaORBService.getCurrent(CorbaORBService.java:222)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:227)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
>  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.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:90)
> {code}
> If I use the context factory class from my local java 8 oracle jdk/open jdk {{com.sun.jndi.cosnaming.CNCtxFactory}} then it works fine.
> I can see that the {{NullPointerException}} is thrown from here
> https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/service/CorbaORBService.java#L277
> which pointing me to suspicion that the iiop library expects a WFLY running to get service registry. But it is not available on client side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 06:36:00 2015
From: issues at jboss.org (Radovan Synek (JIRA))
Date: Tue, 15 Sep 2015 06:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-914) Check KIE API for backward
	compatibility
In-Reply-To: <JIRA.12584936.1442313348000@Atlassian.JIRA>
References: <JIRA.12584936.1442313348000@Atlassian.JIRA>
	<JIRA.12584936.1442313348249@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584936.1442313348000.29329.1442313360057@Atlassian.JIRA>

Radovan Synek created DROOLS-914:
------------------------------------

             Summary: Check KIE API for backward compatibility
                 Key: DROOLS-914
                 URL: https://issues.jboss.org/browse/DROOLS-914
             Project: Drools
          Issue Type: Feature Request
            Reporter: Radovan Synek
            Assignee: Radovan Synek


kie-api should be checked regularly for backward incompatible changes. Proposed solution is to use revapi maven plugin [1].

[1] http://revapi.org



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 07:01:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 15 Sep 2015 07:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-915) LeftTuples don't get deleted
 from segment memories when the segment itself is unlinked
In-Reply-To: <JIRA.12584942.1442314854000@Atlassian.JIRA>
References: <JIRA.12584942.1442314854000@Atlassian.JIRA>
	<JIRA.12584942.1442314854622@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584942.1442314854000.29379.1442314860054@Atlassian.JIRA>

Mario Fusco created DROOLS-915:
----------------------------------

             Summary: LeftTuples don't get deleted from segment memories when the segment itself is unlinked
                 Key: DROOLS-915
                 URL: https://issues.jboss.org/browse/DROOLS-915
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


LeftTuples should be deleted from segment memories when the segment itself is unlinked. At the moment they remain in the segment memory forever until the segment is linked in again. This is not a memory leak because the segment memory cannot grow when the segment itself is unlinked, but just an optimization to free memory as early as possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 07:20:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 15 Sep 2015 07:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
In-Reply-To: <JIRA.12562785.1423556555000@Atlassian.JIRA>
References: <JIRA.12562785.1423556555000@Atlassian.JIRA>
	<JIRA.12562785.1423556555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562785.1423556555000.29458.1442316000420@Atlassian.JIRA>


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

David Lloyd commented on REMJMX-94:
-----------------------------------

I have come up with a possible workaround in the form of a change to the buffer pooling code.  If the thread-local queue length is configured to zero, it will not create the thread local queue.  The system property to control this is {{xnio.bufferpool.threadlocal.size}}.  An updated version of XNIO will be required (3.2.4.Final or higher, 3.3.3.Final or higher).

> Memory leak in remoting-jmx
> ---------------------------
>
>                 Key: REMJMX-94
>                 URL: https://issues.jboss.org/browse/REMJMX-94
>             Project: Remoting JMX
>          Issue Type: Bug
>    Affects Versions: 1.1.3.Final
>            Reporter: Libor Zoubek
>            Assignee: Darran Lofthouse
>              Labels: memory_leak
>             Fix For: 2.0.2.CR1
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org/jboss/remotingjmx/memleak/test/Main.java
> I am not sure if memleak is in remoting-jmx or some other underlying stuff. 
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 07:42:00 2015
From: issues at jboss.org (Radovan Synek (JIRA))
Date: Tue, 15 Sep 2015 07:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-914) Check KIE API for backward
	compatibility
In-Reply-To: <JIRA.12584936.1442313348000@Atlassian.JIRA>
References: <JIRA.12584936.1442313348000@Atlassian.JIRA>
	<JIRA.12584936.1442313348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584936.1442313348000.29525.1442317320040@Atlassian.JIRA>


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

Radovan Synek commented on DROOLS-914:
--------------------------------------

Done by the following PRs:
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/pull/88
https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/100

> Check KIE API for backward compatibility
> ----------------------------------------
>
>                 Key: DROOLS-914
>                 URL: https://issues.jboss.org/browse/DROOLS-914
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Radovan Synek
>            Assignee: Radovan Synek
>
> kie-api should be checked regularly for backward incompatible changes. Proposed solution is to use revapi maven plugin [1].
> [1] http://revapi.org



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 08:03:00 2015
From: issues at jboss.org (Pavan Sharma (JIRA))
Date: Tue, 15 Sep 2015 08:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBFORUMS-308) spring bean setter is not
 working in jboss. Injected bean is getting null while invoking
In-Reply-To: <JIRA.12584907.1442302820000@Atlassian.JIRA>
References: <JIRA.12584907.1442302820000@Atlassian.JIRA>
	<JIRA.12584907.1442302820000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584907.1442302820000.29589.1442318580508@Atlassian.JIRA>


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

Pavan Sharma commented on JBFORUMS-308:
---------------------------------------

Does any one has any clue?

> spring bean setter is not working in jboss. Injected bean is getting null while invoking
> ----------------------------------------------------------------------------------------
>
>                 Key: JBFORUMS-308
>                 URL: https://issues.jboss.org/browse/JBFORUMS-308
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Integration
>            Reporter: Pavan Sharma
>            Assignee: Luca Stancapiano
>
> I am getting one class instance while not for other in same class and defined in same config.xml file. This is working fine when deployed on webSphere & Tomcat but creating issue on Jboss EAP 6.3.
> 1. I have one auth.xml config file that contains below 
> <bean id="loginController" class="com.abc.mvc.controller.auth.LoginController"
> 		parent="abcAbstractCommandController">
> 		<property name="spAuthOperation" ref="spAuthOperation" />
> 		<property name="commandName" value="loginCommand" />
> 		<property name="commandClass"
> 			value="com.abc.mvc.command.auth.LoginCommand" />
> 		<property name="validator" ref="loginValidator" />
> 		<property name="otpAuthJSONBldr" ref="otpAuthJSONBldr" />
> 	</bean>
> <bean id="otpAuthJSONBldr"
> 		class="com.abc.json.builder.auth.OTPAuthJSONBldr"
> 		parent="comJSONBuilder" />
> 2. LoginController.java; In this class i have injected one operation and one jsonBldr that is defined in auth.xml config file.
> public class LoginController extends AbstractCommandController {
> 	SPAuthOperation spAuthOperation;
> 	
>         private ABCJSONBuilder otpAuthJSONBldr;
> 	
>        public SPAuthOperation  getspAuthOperation() {
> 		return spAuthOperation;
> 	}
> 	public void setspAuthOperation(SPAuthOperation  spAuthOperation) {
> 		this.spAuthOperation = spAuthOperation
> 	}
> 	public ABCJSONBuilder getOtpAuthJSONBldr() {
> 		return otpAuthJSONBldr;
> 	}
> 	public void setOtpAuthJSONBldr(ABCJSONBuilder otpAuthJSONBldr1) {
> 		this.otpAuthJSONBldr = otpAuthJSONBldr1;
> 	}
> }
> now when i am trying to invoke logincontroller thru my application then getting spAuthOperation class instance but not otpAuthJSONBldr. this is strange thing.
> Below is the Jboss trace log where also getting 'otpJsonBldr' instance created on server startup but then not getting at runtime and application invocation..
> 2015-09-14 12:38:17,656 [ServerService Thread Pool -- 59] TRACE - Found bean property 'otpAuthJSONBldr' of type [com.abc.json.builder.auth.ABCJSONBuilder]
> {color:red}Creating shared instance of singleton bean 'otpAuthJSONBldr'{color}
> 2015-09-14 12:38:21,833 [ServerService Thread Pool -- 59] DEBUG - Creating instance of bean 'otpAuthJSONBldr'
> 2015-09-14 12:38:21,834 [ServerService Thread Pool -- 59] DEBUG - Eagerly caching bean 'otpAuthJSONBldr' to allow for resolving potential circular references
> 2015-09-14 12:38:21,835 [ServerService Thread Pool -- 59] TRACE - Getting BeanInfo for class [com.abc.json.builder.auth.otpAuthJSONBldr]
> 2015-09-14 12:38:21,837 [ServerService Thread Pool -- 59] TRACE - Caching PropertyDescriptors for class [com.abc.json.builder.authotpAuthJSONBldr]
> -----
> Creating implicit proxy for bean 'otpAuthJSONBldr' with 1 common interceptors and 0 specific interceptors
> 2015-09-14 12:38:21,863 [ServerService Thread Pool -- 59] DEBUG - Creating CGLIB2 proxy:{color:red} target source is SingletonTargetSource for target object [com.abc.json.builder.auth.otpAuthJSONBldr at 10b53e6]{color}
> 2015-09-14 12:38:21,863 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: protected com.abc.json.builder.auth.ABCPayloadHeader com.abc.json.builder.authotpAuthJSONBldr.createHeader(com.abc.json.builder.auth.context.ResponseContext)
> 2015-09-14 12:38:21,864 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: public java.lang.Object com.abc.json.builder.auth.otpAuthJSONBldr.createJSONResponse(com.abc.json.builder.auth.context.ResponseContext)
> 2015-09-14 12:38:21,864 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: protected void com.abc.json.builder.auth.otpAuthJSONBldr.populatePayLoad
> 2015-09-14 12:38:21,882 [ServerService Thread Pool -- 59] DEBUG -{color:red} Finished creating instance of bean 'otpAuthJSONBldr'{color}
> Need input on urgent basis.....
> Thanks In advance



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 08:05:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 15 Sep 2015 08:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-913) Memory leak when deleting a
 tuple from an unlinked segment
In-Reply-To: <JIRA.12584856.1442245949000@Atlassian.JIRA>
References: <JIRA.12584856.1442245949000@Atlassian.JIRA>
	<JIRA.12584856.1442245949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584856.1442245949000.29600.1442318700106@Atlassian.JIRA>


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

Mario Fusco resolved DROOLS-913.
--------------------------------
    Fix Version/s: 6.3.0.Final
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/c527e8d28#diff-0c6315935562fbd4bd02dbae8f10bf08

> Memory leak when deleting a tuple from an unlinked segment
> ----------------------------------------------------------
>
>                 Key: DROOLS-913
>                 URL: https://issues.jboss.org/browse/DROOLS-913
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> When deleting an object from a session all references to the object itself and the fact handle holding it should disappear. Unfortunately, as demonstrated by the test case below, in some case the deleted fact can remain as a deleted left tuple in the memory of an unlinked segment.
> {code}
>     @Test
>     public void testBetaMemoryLeakOnFactDelete() {
>         String drl =
>                 "rule R1 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "    $c : Integer(this == 2)\n" +
>                 "then \n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "then \n" +
>                 "end\n";
>         KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
>                                              .build()
>                                              .newKieSession();
>         FactHandle fh1 = ksession.insert(1);
>         FactHandle fh2 = ksession.insert("test");
>         ksession.fireAllRules();
>         ksession.delete(fh1);
>         ksession.delete(fh2);
>         ksession.fireAllRules();
>         NodeMemories nodeMemories = ((InternalWorkingMemory) ksession).getNodeMemories();
>         for (int i = 0; i < nodeMemories.length(); i++) {
>             Memory memory = nodeMemories.peekNodeMemory( i );
>             if ( memory != null && memory.getSegmentMemory() != null ) {
>                 SegmentMemory segmentMemory = memory.getSegmentMemory();
>                 System.out.println( memory );
>                 LeftTuple deleteFirst = memory.getSegmentMemory().getStagedLeftTuples().getDeleteFirst();
>                 System.out.println( deleteFirst );
>                 assertNull( deleteFirst );
>             }
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 08:13:00 2015
From: issues at jboss.org (Luca Stancapiano (JIRA))
Date: Tue, 15 Sep 2015 08:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBFORUMS-308) spring bean setter is not
 working in jboss. Injected bean is getting null while invoking
In-Reply-To: <JIRA.12584907.1442302820000@Atlassian.JIRA>
References: <JIRA.12584907.1442302820000@Atlassian.JIRA>
	<JIRA.12584907.1442302820000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584907.1442302820000.29635.1442319180284@Atlassian.JIRA>


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

Luca Stancapiano commented on JBFORUMS-308:
-------------------------------------------

it's not the right forum. JBoss Forums (now called Rubia Forums) is a web application that you can find here: https://github.com/flashboss/rubia-forums

For problems on JBoss EAP I suppose you should contact r?the redhat support

> spring bean setter is not working in jboss. Injected bean is getting null while invoking
> ----------------------------------------------------------------------------------------
>
>                 Key: JBFORUMS-308
>                 URL: https://issues.jboss.org/browse/JBFORUMS-308
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Integration
>            Reporter: Pavan Sharma
>            Assignee: Luca Stancapiano
>
> I am getting one class instance while not for other in same class and defined in same config.xml file. This is working fine when deployed on webSphere & Tomcat but creating issue on Jboss EAP 6.3.
> 1. I have one auth.xml config file that contains below 
> <bean id="loginController" class="com.abc.mvc.controller.auth.LoginController"
> 		parent="abcAbstractCommandController">
> 		<property name="spAuthOperation" ref="spAuthOperation" />
> 		<property name="commandName" value="loginCommand" />
> 		<property name="commandClass"
> 			value="com.abc.mvc.command.auth.LoginCommand" />
> 		<property name="validator" ref="loginValidator" />
> 		<property name="otpAuthJSONBldr" ref="otpAuthJSONBldr" />
> 	</bean>
> <bean id="otpAuthJSONBldr"
> 		class="com.abc.json.builder.auth.OTPAuthJSONBldr"
> 		parent="comJSONBuilder" />
> 2. LoginController.java; In this class i have injected one operation and one jsonBldr that is defined in auth.xml config file.
> public class LoginController extends AbstractCommandController {
> 	SPAuthOperation spAuthOperation;
> 	
>         private ABCJSONBuilder otpAuthJSONBldr;
> 	
>        public SPAuthOperation  getspAuthOperation() {
> 		return spAuthOperation;
> 	}
> 	public void setspAuthOperation(SPAuthOperation  spAuthOperation) {
> 		this.spAuthOperation = spAuthOperation
> 	}
> 	public ABCJSONBuilder getOtpAuthJSONBldr() {
> 		return otpAuthJSONBldr;
> 	}
> 	public void setOtpAuthJSONBldr(ABCJSONBuilder otpAuthJSONBldr1) {
> 		this.otpAuthJSONBldr = otpAuthJSONBldr1;
> 	}
> }
> now when i am trying to invoke logincontroller thru my application then getting spAuthOperation class instance but not otpAuthJSONBldr. this is strange thing.
> Below is the Jboss trace log where also getting 'otpJsonBldr' instance created on server startup but then not getting at runtime and application invocation..
> 2015-09-14 12:38:17,656 [ServerService Thread Pool -- 59] TRACE - Found bean property 'otpAuthJSONBldr' of type [com.abc.json.builder.auth.ABCJSONBuilder]
> {color:red}Creating shared instance of singleton bean 'otpAuthJSONBldr'{color}
> 2015-09-14 12:38:21,833 [ServerService Thread Pool -- 59] DEBUG - Creating instance of bean 'otpAuthJSONBldr'
> 2015-09-14 12:38:21,834 [ServerService Thread Pool -- 59] DEBUG - Eagerly caching bean 'otpAuthJSONBldr' to allow for resolving potential circular references
> 2015-09-14 12:38:21,835 [ServerService Thread Pool -- 59] TRACE - Getting BeanInfo for class [com.abc.json.builder.auth.otpAuthJSONBldr]
> 2015-09-14 12:38:21,837 [ServerService Thread Pool -- 59] TRACE - Caching PropertyDescriptors for class [com.abc.json.builder.authotpAuthJSONBldr]
> -----
> Creating implicit proxy for bean 'otpAuthJSONBldr' with 1 common interceptors and 0 specific interceptors
> 2015-09-14 12:38:21,863 [ServerService Thread Pool -- 59] DEBUG - Creating CGLIB2 proxy:{color:red} target source is SingletonTargetSource for target object [com.abc.json.builder.auth.otpAuthJSONBldr at 10b53e6]{color}
> 2015-09-14 12:38:21,863 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: protected com.abc.json.builder.auth.ABCPayloadHeader com.abc.json.builder.authotpAuthJSONBldr.createHeader(com.abc.json.builder.auth.context.ResponseContext)
> 2015-09-14 12:38:21,864 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: public java.lang.Object com.abc.json.builder.auth.otpAuthJSONBldr.createJSONResponse(com.abc.json.builder.auth.context.ResponseContext)
> 2015-09-14 12:38:21,864 [ServerService Thread Pool -- 59] DEBUG - Unable to apply any optimisations to advised method: protected void com.abc.json.builder.auth.otpAuthJSONBldr.populatePayLoad
> 2015-09-14 12:38:21,882 [ServerService Thread Pool -- 59] DEBUG -{color:red} Finished creating instance of bean 'otpAuthJSONBldr'{color}
> Need input on urgent basis.....
> Thanks In advance



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 09:03:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 09:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-892) Create feature for
	jbpm-workitems bundle
In-Reply-To: <JIRA.12582295.1440409249000@Atlassian.JIRA>
References: <JIRA.12582295.1440409249000@Atlassian.JIRA>
	<JIRA.12582295.1440409249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582295.1440409249000.29858.1442322180335@Atlassian.JIRA>


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

RH Bugzilla Integration updated DROOLS-892:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1263260
        Bugzilla Update: Perform


> Create feature for jbpm-workitems bundle
> ----------------------------------------
>
>                 Key: DROOLS-892
>                 URL: https://issues.jboss.org/browse/DROOLS-892
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.3.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>
> In the drools karaf features there is no feature for the jbpm-workitems bundle:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/src/main/filtered-resources/repository/features.xml#L116
> It would be good to add a feature with this bundle used in the fuse-bxms-integ repository to avoid specify a version, and have the possibility to include a range of versions, as we do for other drools bundles used in the fuse-integ-repository. Take a look:
> https://github.com/jboss-integration/fuse-bxms-integ/blob/master/karaf/karaf-features/src/main/resources/features.xml#L41



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 09:31:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 15 Sep 2015 09:31:00 -0400 (EDT)
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.30093.1442323860642@Atlassian.JIRA>


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

Darran Lofthouse updated WFLY-5340:
-----------------------------------
    Fix Version/s: 10.0.0.CR1
                       (was: 10.0.0.CR2)


> 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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 09:31:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 15 Sep 2015 09:31:00 -0400 (EDT)
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.30107.1442323860906@Atlassian.JIRA>


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

Tom Jenkinson reassigned WFLY-5224:
-----------------------------------

      Assignee: Stefano Maestri  (was: Amos Feng)
    Resolution: Done


> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 09:48:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 09:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-892) Create feature for
	jbpm-workitems bundle
In-Reply-To: <JIRA.12582295.1440409249000@Atlassian.JIRA>
References: <JIRA.12582295.1440409249000@Atlassian.JIRA>
	<JIRA.12582295.1440409249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582295.1440409249000.30274.1442324880128@Atlassian.JIRA>


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

RH Bugzilla Integration commented on DROOLS-892:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1263260|https://bugzilla.redhat.com/show_bug.cgi?id=1263260] from NEW to MODIFIED

> Create feature for jbpm-workitems bundle
> ----------------------------------------
>
>                 Key: DROOLS-892
>                 URL: https://issues.jboss.org/browse/DROOLS-892
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.3.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>
> In the drools karaf features there is no feature for the jbpm-workitems bundle:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/src/main/filtered-resources/repository/features.xml#L116
> It would be good to add a feature with this bundle used in the fuse-bxms-integ repository to avoid specify a version, and have the possibility to include a range of versions, as we do for other drools bundles used in the fuse-integ-repository. Take a look:
> https://github.com/jboss-integration/fuse-bxms-integ/blob/master/karaf/karaf-features/src/main/resources/features.xml#L41



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:04:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 10:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-868) CLI if/else is not handling
 special characters strings with parenthesis
In-Reply-To: <JIRA.12580331.1438762375000@Atlassian.JIRA>
References: <JIRA.12580331.1438762375000@Atlassian.JIRA>
	<JIRA.12580331.1438762375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580331.1438762375000.30418.1442325840227@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFCORE-868:
------------------------------------------------

Tomas Hofman <thofman at redhat.com> changed the Status of [bug 1249773|https://bugzilla.redhat.com/show_bug.cgi?id=1249773] from NEW to ASSIGNED

> CLI if/else is not handling special characters strings with parenthesis
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-868
>                 URL: https://issues.jboss.org/browse/WFCORE-868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Tomas Hofman
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.Beta7
>
>
> When using CLI if-else scripting that uses a string that contains parenthesis it fails with the following message:
> Failed to handle 'if (outcome == success && result.value != "a64180c0)e7187af86b435229de904104") of /system-property=test:read-resource': Unexpected operation at 49 in '(outcome == success && result.value != "a64180c0)e7187af86b435229de904104")'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:06:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 10:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-892) Create feature for
	jbpm-workitems bundle
In-Reply-To: <JIRA.12582295.1440409249000@Atlassian.JIRA>
References: <JIRA.12582295.1440409249000@Atlassian.JIRA>
	<JIRA.12582295.1440409249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582295.1440409249000.30423.1442325960396@Atlassian.JIRA>


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

RH Bugzilla Integration commented on DROOLS-892:
------------------------------------------------

Kris Verlaenen <kverlaen at redhat.com> changed the Status of [bug 1263302|https://bugzilla.redhat.com/show_bug.cgi?id=1263302] from NEW to ASSIGNED

> Create feature for jbpm-workitems bundle
> ----------------------------------------
>
>                 Key: DROOLS-892
>                 URL: https://issues.jboss.org/browse/DROOLS-892
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.3.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>
> In the drools karaf features there is no feature for the jbpm-workitems bundle:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/src/main/filtered-resources/repository/features.xml#L116
> It would be good to add a feature with this bundle used in the fuse-bxms-integ repository to avoid specify a version, and have the possibility to include a range of versions, as we do for other drools bundles used in the fuse-integ-repository. Take a look:
> https://github.com/jboss-integration/fuse-bxms-integ/blob/master/karaf/karaf-features/src/main/resources/features.xml#L41



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:16:02 2015
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Tue, 15 Sep 2015 10:16:02 -0400 (EDT)
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.1442326509298@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584964.1442326509000.30486.1442326562445@Atlassian.JIRA>

Gunnar Morling created WFLY-5346:
------------------------------------

             Summary: 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


Hibernate Search 5.5.0.Final was released earlier today.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:26:00 2015
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Tue, 15 Sep 2015 10:26:00 -0400 (EDT)
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.30568.1442327160075@Atlassian.JIRA>


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

Gunnar Morling updated WFLY-5346:
---------------------------------
    Fix Version/s: 10.0.0.CR1


> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:28:00 2015
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 15 Sep 2015 10:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-895) LdapExtLoginModule throws
 FailedLoginException when rolesCtxDN and roleFilter attributes are not set
In-Reply-To: <JIRA.12575139.1434459201000@Atlassian.JIRA>
References: <JIRA.12575139.1434459201000@Atlassian.JIRA>
	<JIRA.12575139.1434459201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575139.1434459201000.30574.1442327280353@Atlassian.JIRA>


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

Peter Skopek commented on SECURITY-895:
---------------------------------------

PR: https://github.com/picketbox/picketbox/pull/48

> LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set
> ----------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-895
>                 URL: https://issues.jboss.org/browse/SECURITY-895
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: PicketBox
>    Affects Versions: PicketBox_4_9_0.Beta2
>            Reporter: Ondrej Lukas
>            Assignee: Peter Skopek
>            Priority: Minor
>              Labels: eap-qe-pool-security
>
> In case when LdapExtLoginModule is correctly configured for authentication, but its attributes rolesCtxDN and roleFilter are not set, then authentication with correct username and password leads to FailedLoginException.
> Expected behavior is that user should be authenticated but no roles should be assigned to them.
> Possible EAP configuration:
> <security-domain name="ldap">
>     <authentication>
>         <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
>             <module-option name="baseFilter" value="(uid={0})"/>
>                 <module-option name="bindDN" value="uid=admin,ou=system"/>
>                 <module-option name="baseCtxDN" value="ou=People,o=MyOrg,o=primary,dc=jboss,dc=org"/>
>                 <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
>                 <module-option name="java.naming.security.authentication" value="simple"/>
>                 <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
>                 <module-option name="bindCredential" value="secret"/>
>         </login-module>
>     </authentication>
> </security-domain>
> In case when these attributes are added
> <module-option name="rolesCtxDN" value="ou=Roles,o=MyOrg,o=primary,dc=jboss,dc=org"/>
> <module-option name="roleFilter" value="(member={0})"/>
> then user is correctly authenticated (even in case when no role is assigned to them).
> It is caused by internal NPE thrown from method rolesSearch in LdapExtLoginModule class on line:
> results = ldapCtx.search(rolesCtxDN, roleFilter, filterArgs, constraints);
> DEBUG [org.jboss.security] (default task-2) PBOX000206: Login failure: javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:284)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:350)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:338)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:148)
> 	at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> 	at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:82)
> 	at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
> 	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:339)
> 	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:356)
> 	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:325)
> 	at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:138)
> 	at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:113)
> 	at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:106)
> 	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:51)
> 	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: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: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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:28:00 2015
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 15 Sep 2015 10:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-909) LdapLoginModule code has
 unnecessary BIND_CREDENTIAL constant
In-Reply-To: <JIRA.12582404.1440488382000@Atlassian.JIRA>
References: <JIRA.12582404.1440488382000@Atlassian.JIRA>
	<JIRA.12582404.1440488382000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582404.1440488382000.30582.1442327280506@Atlassian.JIRA>


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

Peter Skopek commented on SECURITY-909:
---------------------------------------

PR: https://github.com/picketbox/picketbox/pull/48

> LdapLoginModule code has unnecessary BIND_CREDENTIAL constant
> -------------------------------------------------------------
>
>                 Key: SECURITY-909
>                 URL: https://issues.jboss.org/browse/SECURITY-909
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX
>            Reporter: Josef Cacek
>            Assignee: Peter Skopek
>            Priority: Minor
>
> The {{org.jboss.security.auth.spi.LdapLoginModule}} class contains unnecessary constant
> {code}
> private static final String BIND_CREDENTIAL = "bindCredential";
> {code}
> It's only used in {{traceLDAPEnv}} method which is responsible for masking passwords in module options. The "bindCredential" is not a valid option in this login module.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:35:02 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 15 Sep 2015 10:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-916) Upgrade wagon-provider-api
 from 1.0 to at least 2.6,
 so it's since with the rest of the maven/aether dependencies
In-Reply-To: <JIRA.12584969.1442327688000@Atlassian.JIRA>
References: <JIRA.12584969.1442327688000@Atlassian.JIRA>
	<JIRA.12584969.1442327688070@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584969.1442327688000.30631.1442327702498@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-916:
---------------------------------------

             Summary: Upgrade wagon-provider-api from 1.0 to at least 2.6, so it's since with the rest of the maven/aether dependencies
                 Key: DROOLS-916
                 URL: https://issues.jboss.org/browse/DROOLS-916
             Project: Drools
          Issue Type: Task
    Affects Versions: 6.3.0.CR2
            Reporter: Geoffrey De Smet
            Assignee: Michael Biarnes Kiefer
            Priority: Minor


This downgrade in our dependency looks pretty bad.

{code}
[INFO] |  |  +- org.apache.maven.wagon:wagon-provider-api:jar:1.0:test (version managed from 2.6)
[INFO] |  |  +- org.apache.maven.wagon:wagon-file:jar:2.6:test
[INFO] |  |  |  +- commons-lang:commons-lang:jar:2.6:test
{code}

It's probably because the ip-bom overwrites the wagon-provider-api  version.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:36:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 15 Sep 2015 10:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-916) Upgrade wagon-provider-api
 from 1.0 to at least 2.6,
 so it's since with the rest of the maven/aether dependencies
In-Reply-To: <JIRA.12584969.1442327688000@Atlassian.JIRA>
References: <JIRA.12584969.1442327688000@Atlassian.JIRA>
	<JIRA.12584969.1442327688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584969.1442327688000.30643.1442327760355@Atlassian.JIRA>


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

Geoffrey De Smet updated DROOLS-916:
------------------------------------
    Description: 
This downgrade in our dependency looks pretty bad.

{code}
[INFO] |  |  +- org.apache.maven.wagon:wagon-provider-api:jar:1.0:test (version managed from 2.6)
[INFO] |  |  +- org.apache.maven.wagon:wagon-file:jar:2.6:test
[INFO] |  |  |  +- commons-lang:commons-lang:jar:2.6:test
{code}

It's probably because the ip-bom overwrites the wagon-provider-api  version to 1.0 (while transitively it's 2.6).

  was:
This downgrade in our dependency looks pretty bad.

{code}
[INFO] |  |  +- org.apache.maven.wagon:wagon-provider-api:jar:1.0:test (version managed from 2.6)
[INFO] |  |  +- org.apache.maven.wagon:wagon-file:jar:2.6:test
[INFO] |  |  |  +- commons-lang:commons-lang:jar:2.6:test
{code}

It's probably because the ip-bom overwrites the wagon-provider-api  version.



> Upgrade wagon-provider-api from 1.0 to at least 2.6, so it's since with the rest of the maven/aether dependencies
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-916
>                 URL: https://issues.jboss.org/browse/DROOLS-916
>             Project: Drools
>          Issue Type: Task
>    Affects Versions: 6.3.0.CR2
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>            Priority: Minor
>
> This downgrade in our dependency looks pretty bad.
> {code}
> [INFO] |  |  +- org.apache.maven.wagon:wagon-provider-api:jar:1.0:test (version managed from 2.6)
> [INFO] |  |  +- org.apache.maven.wagon:wagon-file:jar:2.6:test
> [INFO] |  |  |  +- commons-lang:commons-lang:jar:2.6:test
> {code}
> It's probably because the ip-bom overwrites the wagon-provider-api  version to 1.0 (while transitively it's 2.6).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:46:01 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 15 Sep 2015 10:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-869) command line option to turn
 off CLI security prompts in non-interactive mode
In-Reply-To: <JIRA.12580481.1438858498000@Atlassian.JIRA>
References: <JIRA.12580481.1438858498000@Atlassian.JIRA>
	<JIRA.12580481.1438858498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580481.1438858498000.30732.1442328361529@Atlassian.JIRA>


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

Alexey Loubyansky reopened WFCORE-869:
--------------------------------------


Re-opening to revert Joe's changes and re-work my previous ones.

> command line option to turn off CLI security prompts in non-interactive mode
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-869
>                 URL: https://issues.jboss.org/browse/WFCORE-869
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Bartosz Spyrko-?mietanko
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.CR1
>
>
> When the management interface is secured using a SSL certificate and the certificate is not trusted by the client, user is shown following dialog to accept the certificate:
> {{Accept certificate? [N]o, [T]emporarily, [P]ermenantly : }}
> The prompt is also shown in non-interactive mode (using --file or --command). If the CLI call is a part of an automated process, this can lead to the process being blocked waiting for user input that never happens.
> If the jboss-cli is executed in non-interactive mode and the SSL certificate is not trusted, process should immediately fail with appropriate message. Username/password authentication prompt already works in this way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 10:47:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 15 Sep 2015 10:47:00 -0400 (EDT)
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.1442328369787@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584974.1442328369000.30734.1442328420268@Atlassian.JIRA>

Harald Pehl created WFLY-5347:
---------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:47:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 15 Sep 2015 10:47:00 -0400 (EDT)
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.30742.1442328420553@Atlassian.JIRA>


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

Harald Pehl updated WFLY-5347:
------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/8075)


> 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
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:48:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 15 Sep 2015 10:48:00 -0400 (EDT)
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.30744.1442328480393@Atlassian.JIRA>


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

Harald Pehl updated WFLY-5347:
------------------------------
    Description: New homepage and bugfixes


> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 10:56:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 10:56:00 -0400 (EDT)
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.30789.1442328960129@Atlassian.JIRA>


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

RH Bugzilla Integration updated WFLY-5340:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1263336
        Bugzilla Update: Perform


> 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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 15 11:12:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 15 Sep 2015 11:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-290) Ensure a sensible default
 timeout on the LDAP connections
In-Reply-To: <JIRA.12584979.1442329906000@Atlassian.JIRA>
References: <JIRA.12584979.1442329906000@Atlassian.JIRA>
	<JIRA.12584979.1442329906240@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584979.1442329906000.30960.1442329920285@Atlassian.JIRA>

Darran Lofthouse created ELY-290:
------------------------------------

             Summary: Ensure a sensible default timeout on the LDAP connections
                 Key: ELY-290
                 URL: https://issues.jboss.org/browse/ELY-290
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: Realms
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Alpha1


By long enough I mean long enough to cope with network performance issues but short enough to prevent permanent hangs.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 13:27:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 13:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-892) Create feature for
	jbpm-workitems bundle
In-Reply-To: <JIRA.12582295.1440409249000@Atlassian.JIRA>
References: <JIRA.12582295.1440409249000@Atlassian.JIRA>
	<JIRA.12582295.1440409249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582295.1440409249000.31728.1442338020214@Atlassian.JIRA>


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

RH Bugzilla Integration commented on DROOLS-892:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1263302|https://bugzilla.redhat.com/show_bug.cgi?id=1263302] from ASSIGNED to MODIFIED

> Create feature for jbpm-workitems bundle
> ----------------------------------------
>
>                 Key: DROOLS-892
>                 URL: https://issues.jboss.org/browse/DROOLS-892
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.3.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>
> In the drools karaf features there is no feature for the jbpm-workitems bundle:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/src/main/filtered-resources/repository/features.xml#L116
> It would be good to add a feature with this bundle used in the fuse-bxms-integ repository to avoid specify a version, and have the possibility to include a range of versions, as we do for other drools bundles used in the fuse-integ-repository. Take a look:
> https://github.com/jboss-integration/fuse-bxms-integ/blob/master/karaf/karaf-features/src/main/resources/features.xml#L41



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 13:35:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 15 Sep 2015 13:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
In-Reply-To: <JIRA.12562785.1423556555000@Atlassian.JIRA>
References: <JIRA.12562785.1423556555000@Atlassian.JIRA>
	<JIRA.12562785.1423556555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562785.1423556555000.31761.1442338500198@Atlassian.JIRA>


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

David Lloyd commented on REMJMX-94:
-----------------------------------

3.0.x does not use a thread local queue.  If there is any kind of memory leak in this version, it's not coming (directly) from the pool, it's coming from somewhere else that references the pool and discards a buffer improperly.

> Memory leak in remoting-jmx
> ---------------------------
>
>                 Key: REMJMX-94
>                 URL: https://issues.jboss.org/browse/REMJMX-94
>             Project: Remoting JMX
>          Issue Type: Bug
>    Affects Versions: 1.1.3.Final
>            Reporter: Libor Zoubek
>            Assignee: Darran Lofthouse
>              Labels: memory_leak
>             Fix For: 2.0.2.CR1
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org/jboss/remotingjmx/memleak/test/Main.java
> I am not sure if memleak is in remoting-jmx or some other underlying stuff. 
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 13:48:00 2015
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 15 Sep 2015 13:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-291) Implement handling of
 CredentialCallback on the server side for the GS2 SASL mechanism
In-Reply-To: <JIRA.12585002.1442339243000@Atlassian.JIRA>
References: <JIRA.12585002.1442339243000@Atlassian.JIRA>
	<JIRA.12585002.1442339243364@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585002.1442339243000.31783.1442339280055@Atlassian.JIRA>

Farah Juma created ELY-291:
------------------------------

             Summary: Implement handling of CredentialCallback on the server side for the GS2 SASL mechanism
                 Key: ELY-291
                 URL: https://issues.jboss.org/browse/ELY-291
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: SASL
            Reporter: Farah Juma
            Assignee: Farah Juma






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 14:23:00 2015
From: issues at jboss.org (Stephen Fikes (JIRA))
Date: Tue, 15 Sep 2015 14:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5348) Propagate transaction timeout
 value for distributed transaction when using JTA and EJB remoting
In-Reply-To: <JIRA.12585006.1442341335000@Atlassian.JIRA>
References: <JIRA.12585006.1442341335000@Atlassian.JIRA>
	<JIRA.12585006.1442341335669@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585006.1442341335000.31827.1442341380073@Atlassian.JIRA>

Stephen Fikes created WFLY-5348:
-----------------------------------

             Summary: Propagate transaction timeout value for distributed transaction when using JTA and EJB remoting
                 Key: WFLY-5348
                 URL: https://issues.jboss.org/browse/WFLY-5348
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 10.0.0.Beta2
            Reporter: Stephen Fikes


When a transaction begins in "server 1" and an EJB remoting request is made to "server 2" the timeout value for the transaction branch in "server 2" is initially set to {{Integer.MAX_VALUE}} which means {{set-tx-query-timeout}} does not work properly on datasources enlisted in the distributed branch of the transaction in server 2. This essentially requests that statement execution not be timed out at all (though in some cases the large value seems to result in abnormally fast timeout after a couple of seconds).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 14:29:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 14:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1060) When starting JBoss AS -b
 should work no matter how I start JBoss AS to bind it to the local
 interface
In-Reply-To: <JIRA.12469850.1341334879000@Atlassian.JIRA>
References: <JIRA.12469850.1341334879000@Atlassian.JIRA>
	<JIRA.12469850.1341334879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469850.1341334879000.31873.1442341740208@Atlassian.JIRA>


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

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

anrobert at redhat.com changed the Status of [bug 1125025|https://bugzilla.redhat.com/show_bug.cgi?id=1125025] from MODIFIED to ON_QA

> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1060
>                 URL: https://issues.jboss.org/browse/WFLY-1060
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>              Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address.  Instead it binds to localhost 127.0.0.1.  It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 14:31:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 15 Sep 2015 14:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5348) Propagate transaction timeout
 value for distributed transaction when using JTA and EJB remoting
In-Reply-To: <JIRA.12585006.1442341335000@Atlassian.JIRA>
References: <JIRA.12585006.1442341335000@Atlassian.JIRA>
	<JIRA.12585006.1442341335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585006.1442341335000.31876.1442341860206@Atlassian.JIRA>


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

David Lloyd commented on WFLY-5348:
-----------------------------------

The protocol actually doesn't have a space for this value.  It will have to wait until at least 11.x where the EJB and transaction wire protocols can be updated as needed.  There will still be no way to propogate this timeout information between a newer node and an older one though.

> Propagate transaction timeout value for distributed transaction when using JTA and EJB remoting
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5348
>                 URL: https://issues.jboss.org/browse/WFLY-5348
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Stephen Fikes
>              Labels: ejb3, jta, transactions
>
> When a transaction begins in "server 1" and an EJB remoting request is made to "server 2" the timeout value for the transaction branch in "server 2" is initially set to {{Integer.MAX_VALUE}} which means {{set-tx-query-timeout}} does not work properly on datasources enlisted in the distributed branch of the transaction in server 2. This essentially requests that statement execution not be timed out at all (though in some cases the large value seems to result in abnormally fast timeout after a couple of seconds).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 14:31:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 15 Sep 2015 14:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-980) The capability registry
 fails to rollback properly
In-Reply-To: <JIRA.12585007.1442341852000@Atlassian.JIRA>
References: <JIRA.12585007.1442341852000@Atlassian.JIRA>
	<JIRA.12585007.1442341852213@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585007.1442341852000.31879.1442341860295@Atlassian.JIRA>

ehsavoie Hugonnet created WFCORE-980:
----------------------------------------

             Summary: The capability registry fails to rollback properly
                 Key: WFCORE-980
                 URL: https://issues.jboss.org/browse/WFCORE-980
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta7
            Reporter: ehsavoie Hugonnet
            Assignee: Brian Stansberry
            Priority: Blocker


If we register an already registered capability at a new RegistrationPoint and the operation rollbacks the registry still has the new RegistrationPoint.
The publishedFullRegistry should be a deep copy of the registry:

Reproducer working with the WFCORE-949 pr:
{code:java}
/socket-binding-group=standard-sockets/socket-binding=management-native:add(port=9999, interface=management)
/core-service=management/management-interface=native-interface:add(socket-binding=native-management, security-realm=ManagementRealm) 
/core-service=management/management-interface=native-interface:add(socket-binding=management-native, security-realm=ManagementRealm)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 14:32:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 15 Sep 2015 14:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-980) The capability registry
 fails to rollback properly
In-Reply-To: <JIRA.12585007.1442341852000@Atlassian.JIRA>
References: <JIRA.12585007.1442341852000@Atlassian.JIRA>
	<JIRA.12585007.1442341852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585007.1442341852000.31882.1442341920096@Atlassian.JIRA>


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

ehsavoie Hugonnet reassigned WFCORE-980:
----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> The capability registry fails to rollback properly
> --------------------------------------------------
>
>                 Key: WFCORE-980
>                 URL: https://issues.jboss.org/browse/WFCORE-980
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta7
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>
> If we register an already registered capability at a new RegistrationPoint and the operation rollbacks the registry still has the new RegistrationPoint.
> The publishedFullRegistry should be a deep copy of the registry:
> Reproducer working with the WFCORE-949 pr:
> {code:java}
> /socket-binding-group=standard-sockets/socket-binding=management-native:add(port=9999, interface=management)
> /core-service=management/management-interface=native-interface:add(socket-binding=native-management, security-realm=ManagementRealm) 
> /core-service=management/management-interface=native-interface:add(socket-binding=management-native, security-realm=ManagementRealm)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 15:57:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 15:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in
	bin
In-Reply-To: <JIRA.12472505.1344994425000@Atlassian.JIRA>
References: <JIRA.12472505.1344994425000@Atlassian.JIRA>
	<JIRA.12472505.1344994425000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472505.1344994425000.32143.1442347020860@Atlassian.JIRA>


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

Brian Stansberry resolved WFCORE-25.
------------------------------------
    Resolution: Done


I'm resolving this as there are domain.ps1, jboss-cli.ps1 and standalone.ps1 scripts in bin. If there is further work to do on these, please file separate issues.

> Windows PowerShell scripts in bin
> ---------------------------------
>
>                 Key: WFCORE-25
>                 URL: https://issues.jboss.org/browse/WFCORE-25
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 15:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 15:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.32150.1442347140452@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-756:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 15:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 15:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-602) Ability to view an objects
 index of it's position in a list.
In-Reply-To: <JIRA.12566092.1426592101000@Atlassian.JIRA>
References: <JIRA.12566092.1426592101000@Atlassian.JIRA>
	<JIRA.12566092.1426592101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566092.1426592101000.32161.1442347140696@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-602:
------------------------------------
        Parent:     (was: WFCORE-603)
    Issue Type: Feature Request  (was: Sub-task)


> Ability to view an objects index of it's position in a list.
> ------------------------------------------------------------
>
>                 Key: WFCORE-602
>                 URL: https://issues.jboss.org/browse/WFCORE-602
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>              Labels: affects_elytron
>
> General improvements are being made to the management model for more fine grained manipulation of complex attributes, amongst these changes will be the ability to insert items at a specific position in a list.
> This feature request is to ask for the ability to see an items index to identify it's position.
> i.e. an end user can call :read-recource and see an items position without needing to count how many items there are in order to identify the position of the next insert.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 16:00:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 16:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-603) Simplify working with
	complex attributes
In-Reply-To: <JIRA.12566094.1426595216000@Atlassian.JIRA>
References: <JIRA.12566094.1426595216000@Atlassian.JIRA>
	<JIRA.12566094.1426595216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566094.1426595216000.32167.1442347201439@Atlassian.JIRA>


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

Brian Stansberry resolved WFCORE-603.
-------------------------------------
    Resolution: Done


> Simplify working with complex attributes
> ----------------------------------------
>
>                 Key: WFCORE-603
>                 URL: https://issues.jboss.org/browse/WFCORE-603
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR1
>
>
> This is umbrella issue for all complex attributes related enhancements and simplifications.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 17:02:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 15 Sep 2015 17:02:00 -0400 (EDT)
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.32373.1442350920396@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5244:
-----------------------------------

I'd like to note that this problem is not fixed in the 10.x branch.  If property is a valid child element to container, the xsd must be updated to indicate this. 

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 17:20:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 15 Sep 2015 17:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5245) [Quickstart]
 application-component-2 fails xml validation in eclipse
In-Reply-To: <JIRA.12583363.1441086268000@Atlassian.JIRA>
References: <JIRA.12583363.1441086268000@Atlassian.JIRA>
	<JIRA.12583363.1441086268000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583363.1441086268000.32454.1442352000376@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5245:
-----------------------------------

Version 10.x of the quickstarts has changed this to http://www.jboss.org/j2ee/schema/jboss-ejb-iiop_1_0.xsd   which works. 

I'm still curious about how many copies of this file exist on our namespace, and whether we should come up with one coherent location for the various XSDs.  If this file were to be updated, for example, it'd need to be updated at both http://www.jboss.org/j2ee/schema/jboss-ejb-iiop_1_0.xsd   and http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"

> [Quickstart] application-component-2 fails xml validation in eclipse
> --------------------------------------------------------------------
>
>                 Key: WFLY-5245
>                 URL: https://issues.jboss.org/browse/WFLY-5245
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> jts/application-component-2/src/main/resources/META-INF/jboss-ejb3.xml  file includes:
> {code}
> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
>                xmlns="http://java.sun.com/xml/ns/javaee"
>                xmlns:iiop="urn:iiop"
>                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-ejb3-2_0.xsd
>                   http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
>                   urn:iiop jboss-ejb-iiop_1_0.xsd"
> {code}
> The line  "urn:iiop jboss-ejb-iiop_1_0.xsd"  is clearly problematic and provides no evidence of where it might pull this xsd from. 
> I suggest replacing it with
>                   urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 19:54:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 19:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.32732.1442361240357@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-310:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)
         Priority: Blocker  (was: Major)


I'm moving this to blocker for CR2. Changing the ignore-unused-configuration default to 'true' isn't necessarily a blocker as we could in theory decide to leave it 'false'. But testing this is revealing issues that occur when the value is 'true' that are definitely blockers.

> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 20:07:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 15 Sep 2015 20:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.32739.1442362020438@Atlassian.JIRA>


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

Ken Wills commented on WFCORE-310:
----------------------------------

Reproducible with:

/profile=default:clone(to-profile="deployment-affected")
/server-group=deployment-group-affected:add(profile="deployment-affected", socket-binding-group="standard-sockets")
/host=fedor.yaberk.int/server-config=server-affected:add(group="deployment-group-affected")
/host=fedor.yaberk.int/server-config=server-affected:start
deploy /home/kwills/a.jar --server-groups=deployment-group-affected
deploy /home/kwills/b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=true)
undeploy a.jar --server-groups=deployment-group-affected
deploy /home/kwills/c.jar --server-groups=deployment-group-affected --name=a.jar
undeploy b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=false)

(Jars are just renamed files from the test, see:
./testsuite/domain/target/DeploymentScenario1442357426056/reconnect-slave-dep*.jar

> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 20:07:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 15 Sep 2015 20:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.32746.1442362020592@Atlassian.JIRA>


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

Ken Wills edited comment on WFCORE-310 at 9/15/15 8:06 PM:
-----------------------------------------------------------

Reproducible with:

/profile=default:clone(to-profile="deployment-affected")
/server-group=deployment-group-affected:add(profile="deployment-affected", socket-binding-group="standard-sockets")
/host=fedor.yaberk.int/server-config=server-affected:add(group="deployment-group-affected")
/host=fedor.yaberk.int/server-config=server-affected:start
deploy /home/kwills/a.jar --server-groups=deployment-group-affected
deploy /home/kwills/b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=true)
undeploy a.jar --server-groups=deployment-group-affected
deploy /home/kwills/c.jar --server-groups=deployment-group-affected --name=a.jar
undeploy b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=false)

(Jars are just renamed files from the test, see:
./testsuite/domain/target/DeploymentScenario1442357426056/reconnect-slave-dep*.jar


was (Author: luck3y):
Reproducible with:

/profile=default:clone(to-profile="deployment-affected")
/server-group=deployment-group-affected:add(profile="deployment-affected", socket-binding-group="standard-sockets")
/host=fedor.yaberk.int/server-config=server-affected:add(group="deployment-group-affected")
/host=fedor.yaberk.int/server-config=server-affected:start
deploy /home/kwills/a.jar --server-groups=deployment-group-affected
deploy /home/kwills/b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=true)
undeploy a.jar --server-groups=deployment-group-affected
deploy /home/kwills/c.jar --server-groups=deployment-group-affected --name=a.jar
undeploy b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=false)

(Jars are just renamed files from the test, see:
./testsuite/domain/target/DeploymentScenario1442357426056/reconnect-slave-dep*.jar

> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 20:07:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 15 Sep 2015 20:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.32755.1442362020951@Atlassian.JIRA>


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

Ken Wills edited comment on WFCORE-310 at 9/15/15 8:06 PM:
-----------------------------------------------------------

Reproducible with:

/profile=default:clone(to-profile="deployment-affected")
/server-group=deployment-group-affected:add(profile="deployment-affected", socket-binding-group="standard-sockets")
/host=fedor.yaberk.int/server-config=server-affected:add(group="deployment-group-affected")
/host=fedor.yaberk.int/server-config=server-affected:start
deploy /home/kwills/a.jar --server-groups=deployment-group-affected
deploy /home/kwills/b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=true)
undeploy a.jar --server-groups=deployment-group-affected
deploy /home/kwills/c.jar --server-groups=deployment-group-affected --name=a.jar
undeploy b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=false)

(Jars are just renamed files from the test, see:
./testsuite/domain/target/DeploymentScenario1442357426056/reconnect-slave-dep*.jar)


was (Author: luck3y):
Reproducible with:

/profile=default:clone(to-profile="deployment-affected")
/server-group=deployment-group-affected:add(profile="deployment-affected", socket-binding-group="standard-sockets")
/host=fedor.yaberk.int/server-config=server-affected:add(group="deployment-group-affected")
/host=fedor.yaberk.int/server-config=server-affected:start
deploy /home/kwills/a.jar --server-groups=deployment-group-affected
deploy /home/kwills/b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=true)
undeploy a.jar --server-groups=deployment-group-affected
deploy /home/kwills/c.jar --server-groups=deployment-group-affected --name=a.jar
undeploy b.jar --server-groups=deployment-group-affected
/host=master:reload(admin-only=false)

(Jars are just renamed files from the test, see:
./testsuite/domain/target/DeploymentScenario1442357426056/reconnect-slave-dep*.jar

> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 20:46:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 20:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-913) Memory leak when deleting a
 tuple from an unlinked segment
In-Reply-To: <JIRA.12584856.1442245949000@Atlassian.JIRA>
References: <JIRA.12584856.1442245949000@Atlassian.JIRA>
	<JIRA.12584856.1442245949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584856.1442245949000.32810.1442364360765@Atlassian.JIRA>


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

RH Bugzilla Integration updated DROOLS-913:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1263495
        Bugzilla Update: Perform


> Memory leak when deleting a tuple from an unlinked segment
> ----------------------------------------------------------
>
>                 Key: DROOLS-913
>                 URL: https://issues.jboss.org/browse/DROOLS-913
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> When deleting an object from a session all references to the object itself and the fact handle holding it should disappear. Unfortunately, as demonstrated by the test case below, in some case the deleted fact can remain as a deleted left tuple in the memory of an unlinked segment.
> {code}
>     @Test
>     public void testBetaMemoryLeakOnFactDelete() {
>         String drl =
>                 "rule R1 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "    $c : Integer(this == 2)\n" +
>                 "then \n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "then \n" +
>                 "end\n";
>         KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
>                                              .build()
>                                              .newKieSession();
>         FactHandle fh1 = ksession.insert(1);
>         FactHandle fh2 = ksession.insert("test");
>         ksession.fireAllRules();
>         ksession.delete(fh1);
>         ksession.delete(fh2);
>         ksession.fireAllRules();
>         NodeMemories nodeMemories = ((InternalWorkingMemory) ksession).getNodeMemories();
>         for (int i = 0; i < nodeMemories.length(); i++) {
>             Memory memory = nodeMemories.peekNodeMemory( i );
>             if ( memory != null && memory.getSegmentMemory() != null ) {
>                 SegmentMemory segmentMemory = memory.getSegmentMemory();
>                 System.out.println( memory );
>                 LeftTuple deleteFirst = memory.getSegmentMemory().getStagedLeftTuples().getDeleteFirst();
>                 System.out.println( deleteFirst );
>                 assertNull( deleteFirst );
>             }
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 20:51:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Sep 2015 20:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-913) Memory leak when deleting a
 tuple from an unlinked segment
In-Reply-To: <JIRA.12584856.1442245949000@Atlassian.JIRA>
References: <JIRA.12584856.1442245949000@Atlassian.JIRA>
	<JIRA.12584856.1442245949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584856.1442245949000.32812.1442364660196@Atlassian.JIRA>


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

RH Bugzilla Integration updated DROOLS-913:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1263495, https://bugzilla.redhat.com/show_bug.cgi?id=1263496  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1263495)


> Memory leak when deleting a tuple from an unlinked segment
> ----------------------------------------------------------
>
>                 Key: DROOLS-913
>                 URL: https://issues.jboss.org/browse/DROOLS-913
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> When deleting an object from a session all references to the object itself and the fact handle holding it should disappear. Unfortunately, as demonstrated by the test case below, in some case the deleted fact can remain as a deleted left tuple in the memory of an unlinked segment.
> {code}
>     @Test
>     public void testBetaMemoryLeakOnFactDelete() {
>         String drl =
>                 "rule R1 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "    $c : Integer(this == 2)\n" +
>                 "then \n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "then \n" +
>                 "end\n";
>         KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
>                                              .build()
>                                              .newKieSession();
>         FactHandle fh1 = ksession.insert(1);
>         FactHandle fh2 = ksession.insert("test");
>         ksession.fireAllRules();
>         ksession.delete(fh1);
>         ksession.delete(fh2);
>         ksession.fireAllRules();
>         NodeMemories nodeMemories = ((InternalWorkingMemory) ksession).getNodeMemories();
>         for (int i = 0; i < nodeMemories.length(); i++) {
>             Memory memory = nodeMemories.peekNodeMemory( i );
>             if ( memory != null && memory.getSegmentMemory() != null ) {
>                 SegmentMemory segmentMemory = memory.getSegmentMemory();
>                 System.out.println( memory );
>                 LeftTuple deleteFirst = memory.getSegmentMemory().getStagedLeftTuples().getDeleteFirst();
>                 System.out.println( deleteFirst );
>                 assertNull( deleteFirst );
>             }
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 21:03:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 21:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-981)
 RemoteDomainConnectionService uses out of date HostInfo data when
 reconnecting
In-Reply-To: <JIRA.12585033.1442365330000@Atlassian.JIRA>
References: <JIRA.12585033.1442365330000@Atlassian.JIRA>
	<JIRA.12585033.1442365330986@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585033.1442365330000.32817.1442365380320@Atlassian.JIRA>

Brian Stansberry created WFCORE-981:
---------------------------------------

             Summary: RemoteDomainConnectionService uses out of date HostInfo data when reconnecting
                 Key: WFCORE-981
                 URL: https://issues.jboss.org/browse/WFCORE-981
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.Beta7
            Reporter: Brian Stansberry
            Priority: Blocker
             Fix For: 2.0.0.CR2


When RemoteDomainConnectionService starts, it calculates a "hostInfo" ModelNode that among other things includes data about what addresses the host is ignoring, and what server groups and socket binding groups are relevant to it if it is ignoring resources unrelated to its servers.

Problem is, this data is never updated if the host's config changes, so if the host needs to reconnect to the master, it sends out-of-date data to the master, and also uses out of date data to process the info that comes back from the master.

We need to figure out how to refresh that data for each connection to the master.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 21:10:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 15 Sep 2015 21:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-981)
 RemoteDomainConnectionService uses out of date HostInfo data when
 reconnecting
In-Reply-To: <JIRA.12585033.1442365330000@Atlassian.JIRA>
References: <JIRA.12585033.1442365330000@Atlassian.JIRA>
	<JIRA.12585033.1442365330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585033.1442365330000.32820.1442365800156@Atlassian.JIRA>


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

Ken Wills reassigned WFCORE-981:
--------------------------------

    Assignee: Ken Wills


> RemoteDomainConnectionService uses out of date HostInfo data when reconnecting
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-981
>                 URL: https://issues.jboss.org/browse/WFCORE-981
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta7
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When RemoteDomainConnectionService starts, it calculates a "hostInfo" ModelNode that among other things includes data about what addresses the host is ignoring, and what server groups and socket binding groups are relevant to it if it is ignoring resources unrelated to its servers.
> Problem is, this data is never updated if the host's config changes, so if the host needs to reconnect to the master, it sends out-of-date data to the master, and also uses out of date data to process the info that comes back from the master.
> We need to figure out how to refresh that data for each connection to the master.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 22:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 22:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-646) Product to Project Schema
	and Model Sync
In-Reply-To: <JIRA.12568717.1429281526000@Atlassian.JIRA>
References: <JIRA.12568717.1429281526000@Atlassian.JIRA>
	<JIRA.12568717.1429281526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568717.1429281526000.33006.1442371140400@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-646:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Product to Project Schema and Model Sync
> ----------------------------------------
>
>                 Key: WFCORE-646
>                 URL: https://issues.jboss.org/browse/WFCORE-646
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> Periodic sync of EAP schemas with WildFly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 22:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 22:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-278) Revisit error message for an
 authentication failure.
In-Reply-To: <JIRA.12536929.1396443828000@Atlassian.JIRA>
References: <JIRA.12536929.1396443828000@Atlassian.JIRA>
	<JIRA.12536929.1396443828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536929.1396443828000.33011.1442371140548@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-278:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Revisit error message for an authentication failure.
> ----------------------------------------------------
>
>                 Key: WFCORE-278
>                 URL: https://issues.jboss.org/browse/WFCORE-278
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> After authentication fails in the CLI the following error message is output: -
> {code}
> Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms
> {code}
> This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 22:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 22:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-103) Add Full Kerberos Support
In-Reply-To: <JIRA.12467133.1337768128000@Atlassian.JIRA>
References: <JIRA.12467133.1337768128000@Atlassian.JIRA>
	<JIRA.12467133.1337768128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467133.1337768128000.33024.1442371140925@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-103:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Add Full Kerberos Support
> -------------------------
>
>                 Key: WFCORE-103
>                 URL: https://issues.jboss.org/browse/WFCORE-103
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: management_security,
>             Fix For: 2.0.0.CR2
>
>
> There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 15 22:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Sep 2015 22:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to
 domain-management module
In-Reply-To: <JIRA.12553769.1412093571000@Atlassian.JIRA>
References: <JIRA.12553769.1412093571000@Atlassian.JIRA>
	<JIRA.12553769.1412093571000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553769.1412093571000.33014.1442371140614@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-137:
------------------------------------
    Fix Version/s: 2.0.0.CR2
                       (was: 2.0.0.CR1)


> Add Kerberos tests to domain-management module
> ----------------------------------------------
>
>                 Key: WFCORE-137
>                 URL: https://issues.jboss.org/browse/WFCORE-137
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 01:24:00 2015
From: issues at jboss.org (Weinan Li (JIRA))
Date: Wed, 16 Sep 2015 01:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5349) Upgrade RESTEasy to
	3.0.13.Final
In-Reply-To: <JIRA.12585042.1442381036000@Atlassian.JIRA>
References: <JIRA.12585042.1442381036000@Atlassian.JIRA>
	<JIRA.12585042.1442381036690@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585042.1442381036000.33139.1442381040052@Atlassian.JIRA>

Weinan Li created WFLY-5349:
-------------------------------

             Summary: Upgrade RESTEasy to 3.0.13.Final
                 Key: WFLY-5349
                 URL: https://issues.jboss.org/browse/WFLY-5349
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: REST
            Reporter: Weinan Li
            Assignee: Weinan Li






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 01:55:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 01:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-982) Improve
 ServerRestartRequiredTestCase.testSocketBinding() when used with
 ignore-unused-configuration
In-Reply-To: <JIRA.12585043.1442382844000@Atlassian.JIRA>
References: <JIRA.12585043.1442382844000@Atlassian.JIRA>
	<JIRA.12585043.1442382844474@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585043.1442382844000.33154.1442382900059@Atlassian.JIRA>

Ken Wills created WFCORE-982:
--------------------------------

             Summary: Improve ServerRestartRequiredTestCase.testSocketBinding() when used with ignore-unused-configuration
                 Key: WFCORE-982
                 URL: https://issues.jboss.org/browse/WFCORE-982
             Project: WildFly Core
          Issue Type: Task
            Reporter: Ken Wills
            Assignee: Ken Wills


Currently this test adds an unused socket-binding-group that it assumes will not be ignored on the slave. Since the SBG is unused, it is ignored.

This test should just actually bind something to use the SBG, so the slave picks it up.

For now, the testsuite host-slave.xml has the bogus reload-sockets added statically.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 02:09:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Wed, 16 Sep 2015 02:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-980) The capability registry
 fails to rollback properly
In-Reply-To: <JIRA.12585007.1442341852000@Atlassian.JIRA>
References: <JIRA.12585007.1442341852000@Atlassian.JIRA>
	<JIRA.12585007.1442341852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585007.1442341852000.33162.1442383740091@Atlassian.JIRA>


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

ehsavoie Hugonnet updated WFCORE-980:
-------------------------------------
    Fix Version/s: 2.0.0.CR2


> The capability registry fails to rollback properly
> --------------------------------------------------
>
>                 Key: WFCORE-980
>                 URL: https://issues.jboss.org/browse/WFCORE-980
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta7
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> If we register an already registered capability at a new RegistrationPoint and the operation rollbacks the registry still has the new RegistrationPoint.
> The publishedFullRegistry should be a deep copy of the registry:
> Reproducer working with the WFCORE-949 pr:
> {code:java}
> /socket-binding-group=standard-sockets/socket-binding=management-native:add(port=9999, interface=management)
> /core-service=management/management-interface=native-interface:add(socket-binding=native-management, security-realm=ManagementRealm) 
> /core-service=management/management-interface=native-interface:add(socket-binding=management-native, security-realm=ManagementRealm)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 02:22:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 02:22:00 -0400 (EDT)
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.33180.1442384520100@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5244:
-----------------------------------

This issue can be worked around by either commenting out the property tag, or uncommenting the configuration tag. 

EAP 7 quickstarts commented out the property.  I'll submit a PR to wildfly quickstarts doing the same, for unity. 

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 02:32:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 02:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5245) [Quickstart]
 application-component-2 fails xml validation in eclipse
In-Reply-To: <JIRA.12583363.1441086268000@Atlassian.JIRA>
References: <JIRA.12583363.1441086268000@Atlassian.JIRA>
	<JIRA.12583363.1441086268000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583363.1441086268000.33197.1442385120194@Atlassian.JIRA>


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

Rob Stryker closed WFLY-5245.
-----------------------------
    Resolution: Duplicate Issue


Duplicate of WFLY-5245

> [Quickstart] application-component-2 fails xml validation in eclipse
> --------------------------------------------------------------------
>
>                 Key: WFLY-5245
>                 URL: https://issues.jboss.org/browse/WFLY-5245
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> jts/application-component-2/src/main/resources/META-INF/jboss-ejb3.xml  file includes:
> {code}
> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
>                xmlns="http://java.sun.com/xml/ns/javaee"
>                xmlns:iiop="urn:iiop"
>                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-ejb3-2_0.xsd
>                   http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
>                   urn:iiop jboss-ejb-iiop_1_0.xsd"
> {code}
> The line  "urn:iiop jboss-ejb-iiop_1_0.xsd"  is clearly problematic and provides no evidence of where it might pull this xsd from. 
> I suggest replacing it with
>                   urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 02:33:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 02:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5245) [Quickstart]
 application-component-2 fails xml validation in eclipse
In-Reply-To: <JIRA.12583363.1441086268000@Atlassian.JIRA>
References: <JIRA.12583363.1441086268000@Atlassian.JIRA>
	<JIRA.12583363.1441086268000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583363.1441086268000.33200.1442385180128@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5245:
-----------------------------------

Wow, I mean Duplicate of WFLY-5250.  

> [Quickstart] application-component-2 fails xml validation in eclipse
> --------------------------------------------------------------------
>
>                 Key: WFLY-5245
>                 URL: https://issues.jboss.org/browse/WFLY-5245
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> jts/application-component-2/src/main/resources/META-INF/jboss-ejb3.xml  file includes:
> {code}
> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
>                xmlns="http://java.sun.com/xml/ns/javaee"
>                xmlns:iiop="urn:iiop"
>                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-ejb3-2_0.xsd
>                   http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
>                   urn:iiop jboss-ejb-iiop_1_0.xsd"
> {code}
> The line  "urn:iiop jboss-ejb-iiop_1_0.xsd"  is clearly problematic and provides no evidence of where it might pull this xsd from. 
> I suggest replacing it with
>                   urn:iiop http://www.jboss.org/schema/jbossas/jboss-ejb-iiop_1_0.xsd"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 02:52:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 02:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5247)
 wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in
 eclipse
In-Reply-To: <JIRA.12583372.1441090578000@Atlassian.JIRA>
References: <JIRA.12583372.1441090578000@Atlassian.JIRA>
	<JIRA.12583372.1441090578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583372.1441090578000.33243.1442386320467@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5247:
-----------------------------------

The wf 9.x quickstarts still suffer from this problem.   The wf10 quickstarts have chosen instead to remove the descriptor entirely (since it was mostly empty), a solution I'm not entirely sure is the best one.   The EAP7 quickstarts on the other hand fleshed out the descriptor a bit more to be a better example to the user. 

I've submitted a PR to align the wf10 and eap7 descriptors. 

> wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in eclipse
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5247
>                 URL: https://issues.jboss.org/browse/WFLY-5247
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate. 
> The xml file jboss-ejb3.xml file inside the project has the following content:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
>     JBoss, Home of Professional Open Source
>     Copyright 2013, Red Hat, Inc. and/or its affiliates, and individual
>     contributors by the @authors tag. See the copyright.txt in the
>     distribution for a full listing of individual contributors.
>     Licensed under the Apache License, Version 2.0 (the "License");
>     you may not use this file except in compliance with the License.
>     You may obtain a copy of the License at
>     http://www.apache.org/licenses/LICENSE-2.0
>     Unless required by applicable law or agreed to in writing, software
>     distributed under the License is distributed on an "AS IS" BASIS,
>     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>     See the License for the specific language governing permissions and
>     limitations under the License.
> -->
> <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:s="urn:security"
>     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">
>     <enterprise-beans>
>     </enterprise-beans>
>     <assembly-descriptor>
>     </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> Unfortunately, the element "enterprise-beans" is not allowed to be empty. 
> A solution is to remove the empty "enterprise-beans" element. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 03:19:00 2015
From: issues at jboss.org (Weinan Li (JIRA))
Date: Wed, 16 Sep 2015 03:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5350) RESTEasy 3.0.13.Final failed
	WildFly tests
In-Reply-To: <JIRA.12585045.1442387906000@Atlassian.JIRA>
References: <JIRA.12585045.1442387906000@Atlassian.JIRA>
	<JIRA.12585045.1442387906022@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585045.1442387906000.33368.1442387940051@Atlassian.JIRA>

Weinan Li created WFLY-5350:
-------------------------------

             Summary: RESTEasy 3.0.13.Final failed WildFly tests
                 Key: WFLY-5350
                 URL: https://issues.jboss.org/browse/WFLY-5350
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: REST
            Reporter: Weinan Li
            Assignee: Weinan Li






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 03:20:00 2015
From: issues at jboss.org (Weinan Li (JIRA))
Date: Wed, 16 Sep 2015 03:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5350) RESTEasy 3.0.13.Final failed
	WildFly tests
In-Reply-To: <JIRA.12585045.1442387906000@Atlassian.JIRA>
References: <JIRA.12585045.1442387906000@Atlassian.JIRA>
	<JIRA.12585045.1442387906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585045.1442387906000.33370.1442388000103@Atlassian.JIRA>


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

Weinan Li closed WFLY-5350.
---------------------------
    Resolution: Done


This should be created in RESTEasy project.

> RESTEasy 3.0.13.Final failed WildFly tests
> ------------------------------------------
>
>                 Key: WFLY-5350
>                 URL: https://issues.jboss.org/browse/WFLY-5350
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: REST
>            Reporter: Weinan Li
>            Assignee: Weinan Li
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 03:29:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 16 Sep 2015 03:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-913) Memory leak when deleting a
 tuple from an unlinked segment
In-Reply-To: <JIRA.12584856.1442245949000@Atlassian.JIRA>
References: <JIRA.12584856.1442245949000@Atlassian.JIRA>
	<JIRA.12584856.1442245949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584856.1442245949000.33416.1442388540148@Atlassian.JIRA>


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

Mario Fusco commented on DROOLS-913:
------------------------------------

The fix also requires this commit https://github.com/droolsjbpm/drools/commit/3df503e5a

> Memory leak when deleting a tuple from an unlinked segment
> ----------------------------------------------------------
>
>                 Key: DROOLS-913
>                 URL: https://issues.jboss.org/browse/DROOLS-913
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> When deleting an object from a session all references to the object itself and the fact handle holding it should disappear. Unfortunately, as demonstrated by the test case below, in some case the deleted fact can remain as a deleted left tuple in the memory of an unlinked segment.
> {code}
>     @Test
>     public void testBetaMemoryLeakOnFactDelete() {
>         String drl =
>                 "rule R1 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "    $c : Integer(this == 2)\n" +
>                 "then \n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "then \n" +
>                 "end\n";
>         KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
>                                              .build()
>                                              .newKieSession();
>         FactHandle fh1 = ksession.insert(1);
>         FactHandle fh2 = ksession.insert("test");
>         ksession.fireAllRules();
>         ksession.delete(fh1);
>         ksession.delete(fh2);
>         ksession.fireAllRules();
>         NodeMemories nodeMemories = ((InternalWorkingMemory) ksession).getNodeMemories();
>         for (int i = 0; i < nodeMemories.length(); i++) {
>             Memory memory = nodeMemories.peekNodeMemory( i );
>             if ( memory != null && memory.getSegmentMemory() != null ) {
>                 SegmentMemory segmentMemory = memory.getSegmentMemory();
>                 System.out.println( memory );
>                 LeftTuple deleteFirst = memory.getSegmentMemory().getStagedLeftTuples().getDeleteFirst();
>                 System.out.println( deleteFirst );
>                 assertNull( deleteFirst );
>             }
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 03:43:00 2015
From: issues at jboss.org (Matthieu Brouillard (JIRA))
Date: Wed, 16 Sep 2015 03:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5351) querying TimerService
 information from CLI fails for canceled timer
In-Reply-To: <JIRA.12585051.1442389327000@Atlassian.JIRA>
References: <JIRA.12585051.1442389327000@Atlassian.JIRA>
	<JIRA.12585051.1442389327000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585051.1442389327000.33464.1442389380117@Atlassian.JIRA>

Matthieu Brouillard created WFLY-5351:
-----------------------------------------

             Summary: querying TimerService information from CLI fails for canceled timer
                 Key: WFLY-5351
                 URL: https://issues.jboss.org/browse/WFLY-5351
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 8.2.1.Final
         Environment: probably not relevant but here is my environment

{{Java Version     : 1.8.0_60
Java Vendor      : Oracle Corporation
OS Hostname      : PAMWX125
OS Architecture  : amd64
OS Name          : Windows 7
}}
            Reporter: Matthieu Brouillard
            Priority: Critical
         Attachments: patch1.diff, timer-cli-failure.zip

When (at least) a persistent calendar timer is created then cancelled, querying TimerService information via CLI (script or library) fails when retrieving also runtime information.

We discovered the issue because our arquillian tests are failing due to some code in arquillian that fires the equivalent of the provided CLI command below when remotes tests are executed.

Attached is a proposed patch and a demo project to reproduce in a simple way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 03:43:00 2015
From: issues at jboss.org (Matthieu Brouillard (JIRA))
Date: Wed, 16 Sep 2015 03:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5351) querying TimerService
 information from CLI fails for canceled timer
In-Reply-To: <JIRA.12585051.1442389327000@Atlassian.JIRA>
References: <JIRA.12585051.1442389327000@Atlassian.JIRA>
	<JIRA.12585051.1442389327000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585051.1442389327000.33466.1442389380217@Atlassian.JIRA>


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

Matthieu Brouillard updated WFLY-5351:
--------------------------------------
    Priority: Major  (was: Critical)


> querying TimerService information from CLI fails for canceled timer
> -------------------------------------------------------------------
>
>                 Key: WFLY-5351
>                 URL: https://issues.jboss.org/browse/WFLY-5351
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.1.Final
>         Environment: probably not relevant but here is my environment
> {{Java Version     : 1.8.0_60
> Java Vendor      : Oracle Corporation
> OS Hostname      : PAMWX125
> OS Architecture  : amd64
> OS Name          : Windows 7
> }}
>            Reporter: Matthieu Brouillard
>         Attachments: patch1.diff, timer-cli-failure.zip
>
>
> When (at least) a persistent calendar timer is created then cancelled, querying TimerService information via CLI (script or library) fails when retrieving also runtime information.
> We discovered the issue because our arquillian tests are failing due to some code in arquillian that fires the equivalent of the provided CLI command below when remotes tests are executed.
> Attached is a proposed patch and a demo project to reproduce in a simple way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 04:24:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 16 Sep 2015 04:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-983) Upgrade wildfly-legacy-test
	to final
In-Reply-To: <JIRA.12585057.1442391780000@Atlassian.JIRA>
References: <JIRA.12585057.1442391780000@Atlassian.JIRA>
	<JIRA.12585057.1442391780136@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585057.1442391780000.33575.1442391840180@Atlassian.JIRA>

Kabir Khan created WFCORE-983:
---------------------------------

             Summary: Upgrade wildfly-legacy-test to final
                 Key: WFCORE-983
                 URL: https://issues.jboss.org/browse/WFCORE-983
             Project: WildFly Core
          Issue Type: Feature Request
            Reporter: Kabir Khan
             Fix For: 2.0.0.CR2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 04:26:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 16 Sep 2015 04:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-983) Upgrade wildfly-legacy-test
	to final
In-Reply-To: <JIRA.12585057.1442391780000@Atlassian.JIRA>
References: <JIRA.12585057.1442391780000@Atlassian.JIRA>
	<JIRA.12585057.1442391780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585057.1442391780000.33586.1442391960932@Atlassian.JIRA>


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

Kabir Khan reassigned WFCORE-983:
---------------------------------

    Assignee: Kabir Khan


> Upgrade wildfly-legacy-test to final
> ------------------------------------
>
>                 Key: WFCORE-983
>                 URL: https://issues.jboss.org/browse/WFCORE-983
>             Project: WildFly Core
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 2.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 04:30:00 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 16 Sep 2015 04:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-984) Scripts for running EAP as
 service on RHEL contains unsupported option "reload" in help message
In-Reply-To: <JIRA.12585059.1442391955000@Atlassian.JIRA>
References: <JIRA.12585059.1442391955000@Atlassian.JIRA>
	<JIRA.12585059.1442391955000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585059.1442391955000.33610.1442392200390@Atlassian.JIRA>


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

Marek Kopeck? moved JBEAP-1079 to WFCORE-984:
---------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-984  (was: JBEAP-1079)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Scripts
                           (was: Scripts)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.Beta4
                           (was: 7.0.0.DR9)


> Scripts for running EAP as service on RHEL contains unsupported option "reload" in help message
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-984
>                 URL: https://issues.jboss.org/browse/WFCORE-984
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> *Description of problem:*
> wildfly-init-redhat.sh contains reload option in help message, but this option is not supported by the script and returns usage message.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME/bin/init.d/
> # ./wildfly-init-redhat.sh reload
> *Actual results:*
> {noformat}Usage: ./wildfly-init-redhat.sh {start|stop|status|restart|reload}{noformat}
> *Expected results:*
> Reload option is not in "Usage message" or reload option is supported by the script.
> *Additional info:*
> * Name of this script will be renamed in EAP (JBEAP-763)
> * 6.x bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=977794
> * Part of script (case for reload is missing):
> {noformat}
> ...
> case "$1" in
> 	start)
> 		start
> 		;;
> 	stop)
> 		stop
> 		;;
> 	restart)
> 		$0 stop
> 		$0 start
> 		;;
> 	status)
> 		status
> 		;;
> 	*)
> 		## If no parameters are given, print which are avaiable.
> 		echo "Usage: $0 {start|stop|status|restart|reload}"
> 		exit 1
> 		;;
> esac
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 16 05:04:00 2015
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Wed, 16 Sep 2015 05:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-903) Differently implemented
 password-stacking option in ClientLoginModule
In-Reply-To: <JIRA.12581986.1440074055000@Atlassian.JIRA>
References: <JIRA.12581986.1440074055000@Atlassian.JIRA>
	<JIRA.12581986.1440074055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581986.1440074055000.33779.1442394240075@Atlassian.JIRA>


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

Ryan Emerson resolved SECURITY-903.
-----------------------------------
    Fix Version/s: PicketBox_5_0_0.Beta1
       Resolution: Done


> Differently implemented password-stacking option in ClientLoginModule
> ---------------------------------------------------------------------
>
>                 Key: SECURITY-903
>                 URL: https://issues.jboss.org/browse/SECURITY-903
>             Project: PicketBox 
>          Issue Type: Bug
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: PicketBox_5_0_0.Beta1
>
>
> From BZ:
> "In case when some login module should use password stacking then value of password-stacking option should be set to useFirstPass. All login modules should respect it. However implemetation of org.jboss.security.ClientLoginModule uses password-stacking differently - it uses password stacking everytime when some value is set for password-stacking option (even value false). It should work same as other login modules. Current behavior can be confusing and can lead to incorrectly set server configuration."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 06:01:00 2015
From: issues at jboss.org (Michal Vinkler (JIRA))
Date: Wed, 16 Sep 2015 06:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5352) Fix the documentation in
 wildfly-singleton_1_0.xsd
In-Reply-To: <JIRA.12585073.1442397609000@Atlassian.JIRA>
References: <JIRA.12585073.1442397609000@Atlassian.JIRA>
	<JIRA.12585073.1442397609261@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585073.1442397609000.34101.1442397660297@Atlassian.JIRA>

Michal Vinkler created WFLY-5352:
------------------------------------

             Summary: Fix the documentation in wildfly-singleton_1_0.xsd
                 Key: WFLY-5352
                 URL: https://issues.jboss.org/browse/WFLY-5352
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Michal Vinkler
            Assignee: Paul Ferraro


https://github.com/wildfly/wildfly/blob/master/clustering/singleton/extension/src/main/resources/schema/wildfly-singleton_1_0.xsd

1. Attributes "name" and "cache-container" have the same documentation. 
2. Attribute "quorum" is missing documentation.

{code:xml}
<xs:complexType name="singleton-policy">
      <!-- ... -->
        <xs:attribute name="name" type="xs:string" use="required">
            <xs:annotation>
                <xs:documentation>Identifies the cache-container used to back the singleton deployment policy.</xs:documentation>
            </xs:annotation>
        </xs:attribute>
        <xs:attribute name="cache-container" type="xs:string" use="required">
            <xs:annotation>
                <xs:documentation>Identifies the cache-container used to back the singleton deployment policy.</xs:documentation>
            </xs:annotation>
        </xs:attribute>
       <!-- ... -->
        <xs:attribute name="quorum" type="xs:integer" default="1">
            <xs:annotation>
                <xs:documentation></xs:documentation>
            </xs:annotation>
        </xs:attribute>
    </xs:complexType>
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 07:27:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Wed, 16 Sep 2015 07:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5345) Remote client EJB IIOP lookup
 fails when wfly context factory lookup is used
In-Reply-To: <JIRA.12584932.1442312279000@Atlassian.JIRA>
References: <JIRA.12584932.1442312279000@Atlassian.JIRA>
	<JIRA.12584932.1442312279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584932.1442312279000.34300.1442402820176@Atlassian.JIRA>


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

Tomasz Adamski closed WFLY-5345.
--------------------------------
    Resolution: Rejected


com.sun.jndi.cosnaming.CNCtxFactory should be used from standalone client. CNCtxFactory in iiop-openjdk is meant to be used inside the application server

> Remote client EJB IIOP lookup fails when wfly context factory lookup is used
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5345
>                 URL: https://issues.jboss.org/browse/WFLY-5345
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>
> I'm not 100% sure that this is a bug as there could be some misconfiguration from my side. Plus I do not know if wildfly-iiop-openjdk is expected to be used on client side.
> When I try to use ejb lookup from client side with usage of IIOP
> {code}
>         System.setProperty("com.sun.CORBA.ORBUseDynamicStub", "true");
>         final Properties prope = new Properties();
>         prope.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory");
>         prope.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.iiop.naming:org.jboss.naming.client");
>         prope.put(Context.PROVIDER_URL, "corbaloc::" + serverName +":3528/JBoss/Naming/root");
>         final InitialContext context = new InitialContext(prope);
>         final Object ejbHome = context.lookup(beanClass.getSimpleName());
>         return homeClass.cast(PortableRemoteObject.narrow(ejbHome, homeClass));
> {code}
> I get exception
> {code}
> java.lang.NullPointerException: null
>  at org.wildfly.iiop.openjdk.service.CorbaORBService.getCurrent(CorbaORBService.java:222)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:227)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
>  at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
>  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.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:90)
> {code}
> If I use the context factory class from my local java 8 oracle jdk/open jdk {{com.sun.jndi.cosnaming.CNCtxFactory}} then it works fine.
> I can see that the {{NullPointerException}} is thrown from here
> https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/service/CorbaORBService.java#L277
> which pointing me to suspicion that the iiop library expects a WFLY running to get service registry. But it is not available on client side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 16 08:32:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 16 Sep 2015 08:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5353) Unable to set resolve-hosts
	for access-log
In-Reply-To: <JIRA.12585103.1442406697000@Atlassian.JIRA>
References: <JIRA.12585103.1442406697000@Atlassian.JIRA>
	<JIRA.12585103.1442406697191@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585103.1442406697000.34562.1442406720818@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5353:
--------------------------------------

             Summary: Unable to set resolve-hosts for access-log
                 Key: WFLY-5353
                 URL: https://issues.jboss.org/browse/WFLY-5353
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Critical


In previous versions of EAP (Web subsystem) there was possible to enable resolving hosts for access logging. This is not possible to enable with Undertow.

Steps for enabling in JBoss Web:
This was accomplished by setting {{resolve-hosts}} attribute of access-log to {{true}} ({{/subsystem=web/virtual-server=default-host/configuration=access-log:add(resolve-hosts=true)}}) and enabling lookups for connector ({{/subsystem=web/connector=http:write-attribute(name=enable-lookups, value=true)}}).

In Undertow subsystem there is only possible to enable resolving peer address ({{/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=resolve-peer-address, value=true)}}), which doesn't have by itself any impact on output in access-log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 08:32:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 16 Sep 2015 08:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5353) Unable to set resolve-hosts
	for access-log
In-Reply-To: <JIRA.12585103.1442406697000@Atlassian.JIRA>
References: <JIRA.12585103.1442406697000@Atlassian.JIRA>
	<JIRA.12585103.1442406697000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585103.1442406697000.34565.1442406720902@Atlassian.JIRA>


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

Radim Hatlapatka updated WFLY-5353:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> Unable to set resolve-hosts for access-log
> ------------------------------------------
>
>                 Key: WFLY-5353
>                 URL: https://issues.jboss.org/browse/WFLY-5353
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> In previous versions of EAP (Web subsystem) there was possible to enable resolving hosts for access logging. This is not possible to enable with Undertow.
> Steps for enabling in JBoss Web:
> This was accomplished by setting {{resolve-hosts}} attribute of access-log to {{true}} ({{/subsystem=web/virtual-server=default-host/configuration=access-log:add(resolve-hosts=true)}}) and enabling lookups for connector ({{/subsystem=web/connector=http:write-attribute(name=enable-lookups, value=true)}}).
> In Undertow subsystem there is only possible to enable resolving peer address ({{/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=resolve-peer-address, value=true)}}), which doesn't have by itself any impact on output in access-log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 11:02:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 16 Sep 2015 11:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-917) Replace XSD referecnes to
 java.sun.com with xmlns.jcp.org
In-Reply-To: <JIRA.12585128.1442415688000@Atlassian.JIRA>
References: <JIRA.12585128.1442415688000@Atlassian.JIRA>
	<JIRA.12585128.1442415688794@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585128.1442415688000.35277.1442415720280@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-917:
---------------------------------------

             Summary: Replace XSD referecnes to java.sun.com with xmlns.jcp.org
                 Key: DROOLS-917
                 URL: https://issues.jboss.org/browse/DROOLS-917
             Project: Drools
          Issue Type: Task
            Reporter: Geoffrey De Smet
            Assignee: Marco Rietveld
            Priority: Optional


In persistence.xml's such as the one in drools-persistence-jpa, don't use XSD schema url's that are old:

Before:
{code}
<persistence ... xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
{code}

After:
{code}
<persistence ... xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_0.xsd">
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 11:20:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 16 Sep 2015 11:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1965) Change default thread pool
 rejection policy to "abort"
In-Reply-To: <JIRA.12585135.1442416765000@Atlassian.JIRA>
References: <JIRA.12585135.1442416765000@Atlassian.JIRA>
	<JIRA.12585135.1442416765229@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585135.1442416765000.35349.1442416800137@Atlassian.JIRA>

Paul Ferraro created JGRP-1965:
----------------------------------

             Summary: Change default thread pool rejection policy to "abort"
                 Key: JGRP-1965
                 URL: https://issues.jboss.org/browse/JGRP-1965
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.6.6
            Reporter: Paul Ferraro
            Assignee: Bela Ban


Currently, JGroups transport thread pools use discard as a rejection policy.  Thus if there are no available threads, and the queue is full, the executor will silently drop the task.
Abort will throw a RejectedExecutionException, in which case, which JGroups catches to populate the num_rejected_msgs statistic.  This is a better default, so that users can monitor this value to determine whether or not to modify their thread pool configuration.  Otherwise, num_rejected_msgs is 0, which might be a source of confusion.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 12:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-980) The capability registry
 fails to rollback properly
In-Reply-To: <JIRA.12585007.1442341852000@Atlassian.JIRA>
References: <JIRA.12585007.1442341852000@Atlassian.JIRA>
	<JIRA.12585007.1442341852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585007.1442341852000.35808.1442421600134@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-980:
-----------------------------------------

I already resolved this, but can you add a unit test of this in the controller module test suite? AbstractCapabilityResolutionTestCase has infrastructure for this kind of testing.

> The capability registry fails to rollback properly
> --------------------------------------------------
>
>                 Key: WFCORE-980
>                 URL: https://issues.jboss.org/browse/WFCORE-980
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta7
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> If we register an already registered capability at a new RegistrationPoint and the operation rollbacks the registry still has the new RegistrationPoint.
> The publishedFullRegistry should be a deep copy of the registry:
> Reproducer working with the WFCORE-949 pr:
> {code:java}
> /socket-binding-group=standard-sockets/socket-binding=management-native:add(port=9999, interface=management)
> /core-service=management/management-interface=native-interface:add(socket-binding=native-management, security-realm=ManagementRealm) 
> /core-service=management/management-interface=native-interface:add(socket-binding=management-native, security-realm=ManagementRealm)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:44:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 12:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-876) Reload or Shutdown inside IF
 statement is performed before the if/else block batch is executed
In-Reply-To: <JIRA.12580927.1439365963000@Atlassian.JIRA>
References: <JIRA.12580927.1439365963000@Atlassian.JIRA>
	<JIRA.12580927.1439365963000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580927.1439365963000.35827.1442421840224@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-876:
------------------------------------
    Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2015-September/004404.html


> Reload or Shutdown inside IF statement is performed before the if/else block batch is executed
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-876
>                 URL: https://issues.jboss.org/browse/WFCORE-876
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Joe Wertz
>            Assignee: Alexey Loubyansky
>
> Executing a reload or shutdown inside an if/else block results in the reload or restart occurring before the other commands in the batch are executed.
> {code}
> if (outcome == success) of /subsystem=logging/logger=org.jboss.as.cli:read-resource()
>    /subsystem=logging:write-attribute(name=use-deployment-logging-config
>    shutdown --restart=true
> end-if
> {code}
> This command will actually leave the server in a reload-required state. The shutdown, or reload, will occur before the write-attribute is executed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:53:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.35862.1442422380185@Atlassian.JIRA>


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

Ken Wills updated WFCORE-979:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
>                 Key: WFCORE-979
>                 URL: https://issues.jboss.org/browse/WFCORE-979
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
>  testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >  
> >      <domain-controller>
> >          <!-- Remote domain controller configuration with a host and port -->
> > -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:53:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.35866.1442422380300@Atlassian.JIRA>


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

Ken Wills updated WFCORE-931:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:53:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-937) --std-out=discard for
 embedded host controller doesn't work
In-Reply-To: <JIRA.12583210.1441006072000@Atlassian.JIRA>
References: <JIRA.12583210.1441006072000@Atlassian.JIRA>
	<JIRA.12583210.1441006072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583210.1441006072000.35869.1442422380468@Atlassian.JIRA>


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

Ken Wills updated WFCORE-937:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> --std-out=discard for embedded host controller doesn't work
> -----------------------------------------------------------
>
>                 Key: WFCORE-937
>                 URL: https://issues.jboss.org/browse/WFCORE-937
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Embedded host controller always prints the logs to the console no matter which --std-out= value I choose.
> {noformat}
> [disconnected /] embed-host-controller --std-out=discard
> 09:22:06,627 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.3.Final
> 09:22:06,733 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
> 09:22:06,758 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 09:22:07,769 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,799 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,824 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,843 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:08,067 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) (Host Controller) started in 1353ms - Started 25 of 27 services (8 services are lazy, passive or on-demand)
> [domain at embedded /] stop-embedded-host-controller 
> 09:22:15,926 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 5ms
> [disconnected /] exit 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:54:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-939) Embedded host controller
 should set launch type attribute to EMBEDDED
In-Reply-To: <JIRA.12583251.1441022081000@Atlassian.JIRA>
References: <JIRA.12583251.1441022081000@Atlassian.JIRA>
	<JIRA.12583251.1441022081000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583251.1441022081000.35873.1442422440331@Atlassian.JIRA>


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

Ken Wills updated WFCORE-939:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> Embedded host controller should set launch type attribute to EMBEDDED
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-939
>                 URL: https://issues.jboss.org/browse/WFCORE-939
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded. 
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
>     /** The manner in which a server can be launched */
>     public static enum LaunchType {
>         /** Launched by a Host Controller in a managed domain */
>         DOMAIN(ProcessType.DOMAIN_SERVER),
>         /** Launched from the command line */
>         STANDALONE(ProcessType.STANDALONE_SERVER),
>         /** Launched by another process in which the server is embedded */
>         EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type              STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type              DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server 
> launch-type              EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type              DOMAIN
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:54:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-945) Cannot start embedded host
 controller in non-modular classloading environment
In-Reply-To: <JIRA.12583562.1441195388000@Atlassian.JIRA>
References: <JIRA.12583562.1441195388000@Atlassian.JIRA>
	<JIRA.12583562.1441195388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583562.1441195388000.35876.1442422440399@Atlassian.JIRA>


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

Ken Wills updated WFCORE-945:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> Cannot start embedded host controller in non-modular classloading environment
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-945
>                 URL: https://issues.jboss.org/browse/WFCORE-945
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Trying to start embedded host controller inside CLI running i in non-modular classloading environment gives me NPE.
> {noformat}
> $ unzip -q jboss-eap-7.0.0.DR9.zip 
> $ cd jboss-eap-7.0/bin/client/
> $ pwd
> /home/hudson/users-tmp/pkremens/jboss-eap-7.0/bin/client
> $ java -jar jboss-cli-client.jar 
> WARN: can't find jboss-cli.xml. Using default configuration values.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
> [standalone at embedded /] stop-embedded-server 
> [disconnected /] embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Failed to handle 'embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0': java.lang.NullPointerException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:55:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-982) Improve
 ServerRestartRequiredTestCase.testSocketBinding() when used with
 ignore-unused-configuration
In-Reply-To: <JIRA.12585043.1442382844000@Atlassian.JIRA>
References: <JIRA.12585043.1442382844000@Atlassian.JIRA>
	<JIRA.12585043.1442382844000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585043.1442382844000.35880.1442422500329@Atlassian.JIRA>


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

Ken Wills updated WFCORE-982:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> Improve ServerRestartRequiredTestCase.testSocketBinding() when used with ignore-unused-configuration
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-982
>                 URL: https://issues.jboss.org/browse/WFCORE-982
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Currently this test adds an unused socket-binding-group that it assumes will not be ignored on the slave. Since the SBG is unused, it is ignored.
> This test should just actually bind something to use the SBG, so the slave picks it up.
> For now, the testsuite host-slave.xml has the bogus reload-sockets added statically.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:55:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-932) stop-embedded-server stops
 the embedded host controller and vice versa
In-Reply-To: <JIRA.12583124.1440765129000@Atlassian.JIRA>
References: <JIRA.12583124.1440765129000@Atlassian.JIRA>
	<JIRA.12583124.1440765129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583124.1440765129000.35883.1442422500396@Atlassian.JIRA>


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

Ken Wills updated WFCORE-932:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> stop-embedded-server stops the embedded host controller and vice versa
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-932
>                 URL: https://issues.jboss.org/browse/WFCORE-932
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> We have four new commands for controlling the lifecycle of embedded instances:
> * *embed-server* - launch embedded standalone
> * *stop-embedded-server* - stop embedded standalone
> * *embed-host-controller* - launch embedded host
> * *stop-embedded-host-controller* - stop embedded host
> \\
> I am able stop embedded standalone by *stop-embedded-host-controller* and embedded host controller by *stop-embedded-server*.
> {noformat}
> [disconnected /] embed-server 
> [standalone at embedded /] stop-embedded-host-controller 
> [disconnected /] embed-host-controller 
> 14:22:18,781 INFO  [org.jboss.modules] (AeshProcess: 15) JBoss Modules version 1.4.3.Final
> [domain at embedded /] stop-embedded-server 
> [disconnected /]
> {noformat}
> \\
> A question comes to my mind, do we need two commands for stopping the embedded instance?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 12:55:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 16 Sep 2015 12:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-933) Embedded server start
 commands are lacking argument validation
In-Reply-To: <JIRA.12583128.1440766459000@Atlassian.JIRA>
References: <JIRA.12583128.1440766459000@Atlassian.JIRA>
	<JIRA.12583128.1440766459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583128.1440766459000.35887.1442422500485@Atlassian.JIRA>


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

Ken Wills updated WFCORE-933:
-----------------------------
    Fix Version/s: 2.0.0.CR2


> Embedded server start commands are lacking argument validation
> --------------------------------------------------------------
>
>                 Key: WFCORE-933
>                 URL: https://issues.jboss.org/browse/WFCORE-933
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> Commands for starting embedded instances are lacking argument validation.
> {noformat}[disconnected /] embed-server foo
> [standalone at embedded /]
> [disconnected /] embed-server foo -foo
> [standalone at embedded /]
> [disconnected /] embed-server foo --foo
> [standalone at embedded /]
> [standalone at embedded /] stop-embedded-server foo
> The command accepts 0 unnamed argument(s) but received: [foo]
> [standalone at embedded /] stop-embedded-server -foo
> Unrecognized arguments: [-foo]
> [standalone at embedded /] stop-embedded-server --foo
> Unrecognized arguments: [--foo]{noformat}
> Same case for embedded host controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 14:41:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 16 Sep 2015 14:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5354) CacheServiceProviderRegistry
 creates unnecessary tx on new member join
In-Reply-To: <JIRA.12585158.1442428851000@Atlassian.JIRA>
References: <JIRA.12585158.1442428851000@Atlassian.JIRA>
	<JIRA.12585158.1442428851961@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585158.1442428851000.36389.1442428860628@Atlassian.JIRA>

Paul Ferraro created WFLY-5354:
----------------------------------

             Summary: CacheServiceProviderRegistry creates unnecessary tx on new member join
                 Key: WFLY-5354
                 URL: https://issues.jboss.org/browse/WFLY-5354
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 14:46:01 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 16 Sep 2015 14:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5355) CacheServiceProviderRegistry
 close() not entirely thread-safe
In-Reply-To: <JIRA.12585159.1442429113000@Atlassian.JIRA>
References: <JIRA.12585159.1442429113000@Atlassian.JIRA>
	<JIRA.12585159.1442429113846@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585159.1442429113000.36485.1442429161079@Atlassian.JIRA>

Paul Ferraro created WFLY-5355:
----------------------------------

             Summary: CacheServiceProviderRegistry close() not entirely thread-safe
                 Key: WFLY-5355
                 URL: https://issues.jboss.org/browse/WFLY-5355
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Beta2
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


CacheServiceProviderRegistry.close() first does a cache lookup of the nodes providing a service, then attempts to modify the resulting set.  However, if another node either creates or removes a new service provider registration for the same service, the resulting set of nodes can be inconsistent.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:32:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 15:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-384) jboss-web_8_0.xsd Eclipse
 validation errors
In-Reply-To: <JIRA.12561384.1421872056000@Atlassian.JIRA>
References: <JIRA.12561384.1421872056000@Atlassian.JIRA>
	<JIRA.12561384.1421872056000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561384.1421872056000.36809.1442431920255@Atlassian.JIRA>


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

Rob Stryker commented on JBMETA-384:
------------------------------------

I've opened a new PR (https://github.com/jboss/metadata/pull/92)  since Denis seems to have stalled on his (https://github.com/jboss/metadata/pull/78)





> jboss-web_8_0.xsd Eclipse validation errors
> -------------------------------------------
>
>                 Key: JBMETA-384
>                 URL: https://issues.jboss.org/browse/JBMETA-384
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>            Reporter: Denis Golovin
>            Assignee: Jean-Frederic Clere
>
> Eclipse validation reports error in xsd file:
> 1. https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_8_0.xsd#L75
> {code}src-resolve.4.2: Error resolving component 'javaee:string'. It was detected that 'javaee:string' is in 
>  namespace 'http://xmlns.jcp.org/xml/ns/javaee', but components from this namespace are not 
>  referenceable from schema document 'file:///home/eskimo/workspace/javaee-mars/a1/WebContent/WEB-
>  INF/jboss-web_8_0.xsd'. If this is the incorrect namespace, perhaps the prefix of 'javaee:string' needs to 
>  be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:///
>  home/eskimo/workspace/javaee-mars/a1/WebContent/WEB-INF/jboss-web_8_0.xsd'.{code}
> 2. https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_8_0.xsd#L299
> {code}src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When
>  <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if
>  restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is
>  specified, a simple type. 'boolean' satisfies none of these conditions.{code}
> 3. It seems missing 
> {code}<xsd:include schemaLocation="jboss-common_6_0.xml" />{code}
> for schema that defines two types and a group listed below:
> {code}jboss:security-domainType
> jboss:security-roleType
> jboss:jndiEnvironmentRefsGroup{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:34:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 15:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-384) jboss-web_8_0.xsd Eclipse
 validation errors
In-Reply-To: <JIRA.12561384.1421872056000@Atlassian.JIRA>
References: <JIRA.12561384.1421872056000@Atlassian.JIRA>
	<JIRA.12561384.1421872056000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561384.1421872056000.36840.1442432040613@Atlassian.JIRA>


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

Rob Stryker commented on JBMETA-384:
------------------------------------

[~wolfc] [~brian.stansberry]  Pinging some who may know how to triage and target this issue properly. 

> jboss-web_8_0.xsd Eclipse validation errors
> -------------------------------------------
>
>                 Key: JBMETA-384
>                 URL: https://issues.jboss.org/browse/JBMETA-384
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>            Reporter: Denis Golovin
>            Assignee: Jean-Frederic Clere
>
> Eclipse validation reports error in xsd file:
> 1. https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_8_0.xsd#L75
> {code}src-resolve.4.2: Error resolving component 'javaee:string'. It was detected that 'javaee:string' is in 
>  namespace 'http://xmlns.jcp.org/xml/ns/javaee', but components from this namespace are not 
>  referenceable from schema document 'file:///home/eskimo/workspace/javaee-mars/a1/WebContent/WEB-
>  INF/jboss-web_8_0.xsd'. If this is the incorrect namespace, perhaps the prefix of 'javaee:string' needs to 
>  be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:///
>  home/eskimo/workspace/javaee-mars/a1/WebContent/WEB-INF/jboss-web_8_0.xsd'.{code}
> 2. https://github.com/jboss/metadata/blob/master/web/src/main/resources/schema/jboss-web_8_0.xsd#L299
> {code}src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When
>  <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if
>  restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is
>  specified, a simple type. 'boolean' satisfies none of these conditions.{code}
> 3. It seems missing 
> {code}<xsd:include schemaLocation="jboss-common_6_0.xml" />{code}
> for schema that defines two types and a group listed below:
> {code}jboss:security-domainType
> jboss:security-roleType
> jboss:jndiEnvironmentRefsGroup{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 15:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-579) ProxyMetadataSource does not
 return JDK8 'default' methods from interfaces
In-Reply-To: <JIRA.12564875.1425547305000@Atlassian.JIRA>
References: <JIRA.12564875.1425547305000@Atlassian.JIRA>
	<JIRA.12564875.1425547305000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564875.1425547305000.36878.1442432340159@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-579:
------------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly-core/pull/541)


> ProxyMetadataSource does not return JDK8 'default' methods from interfaces
> --------------------------------------------------------------------------
>
>                 Key: WFCORE-579
>                 URL: https://issues.jboss.org/browse/WFCORE-579
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 1.0.0.Alpha19
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:41:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 15:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-579) ProxyMetadataSource does not
 return JDK8 'default' methods from interfaces
In-Reply-To: <JIRA.12564875.1425547305000@Atlassian.JIRA>
References: <JIRA.12564875.1425547305000@Atlassian.JIRA>
	<JIRA.12564875.1425547305000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564875.1425547305000.36897.1442432460657@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-579:
-----------------------------------------

I'm guessing at the exact nature of the relationship between WFCORE-579 and WFCORE-725, but my understanding of the comments on the rejected PR for 579 is that 725 fixes 579.

> ProxyMetadataSource does not return JDK8 'default' methods from interfaces
> --------------------------------------------------------------------------
>
>                 Key: WFCORE-579
>                 URL: https://issues.jboss.org/browse/WFCORE-579
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 1.0.0.Alpha19
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:41:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 15:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-579) ProxyMetadataSource does not
 return JDK8 'default' methods from interfaces
In-Reply-To: <JIRA.12564875.1425547305000@Atlassian.JIRA>
References: <JIRA.12564875.1425547305000@Atlassian.JIRA>
	<JIRA.12564875.1425547305000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564875.1425547305000.36906.1442432460843@Atlassian.JIRA>


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

Brian Stansberry resolved WFCORE-579.
-------------------------------------
    Fix Version/s: 2.0.0.CR1
         Assignee: Stuart Douglas  (was: Bartosz Baranowski)
       Resolution: Done


> ProxyMetadataSource does not return JDK8 'default' methods from interfaces
> --------------------------------------------------------------------------
>
>                 Key: WFCORE-579
>                 URL: https://issues.jboss.org/browse/WFCORE-579
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 1.0.0.Alpha19
>            Reporter: Bartosz Baranowski
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 2.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:43:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 15:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-433) git backend for
 loading/storing the configuration XML for wildfly
In-Reply-To: <JIRA.12544076.1402993830000@Atlassian.JIRA>
References: <JIRA.12544076.1402993830000@Atlassian.JIRA>
	<JIRA.12544076.1402993830000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544076.1402993830000.36933.1442432580685@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-433:
------------------------------------
    Priority: Major  (was: Critical)


Reducing priority as Alexey's discussions early this year with the teams doing cloud and provisioning work indicated that different approaches to config persistence were no longer a high priority.

> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
>                 Key: WFCORE-433
>                 URL: https://issues.jboss.org/browse/WFCORE-433
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: James Strachan
>            Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:43:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 15:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-328) Provide deployment manifest
 information via the CLI
In-Reply-To: <JIRA.12485602.1361826111000@Atlassian.JIRA>
References: <JIRA.12485602.1361826111000@Atlassian.JIRA>
	<JIRA.12485602.1361826111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485602.1361826111000.36942.1442432580962@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-328:
------------------------------------
    Priority: Major  (was: Critical)


> Provide deployment manifest information via the CLI
> ---------------------------------------------------
>
>                 Key: WFCORE-328
>                 URL: https://issues.jboss.org/browse/WFCORE-328
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI, Domain Management
>            Reporter: Brian Stansberry
>
> We've gotten a user request for providing the contents of a deployment's MANIFEST.MF via the CLI.
> The request is to include an option to get the manifest info for a single deployment, and also the info for all deployments.
> This task needs to be evaluated in relationship to the larger request to provide read (and possibly in some cases write) access to all files within a deployment. The manifest is essentially just one file with a standard location.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:58:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 15:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-790) CLI Does Not Log History
 With "--file" and "--command(s)" args
In-Reply-To: <JIRA.12576881.1435835622000@Atlassian.JIRA>
References: <JIRA.12576881.1435835622000@Atlassian.JIRA>
	<JIRA.12576881.1435835622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576881.1435835622000.37079.1442433480318@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-790:
-----------------------------------------

This should be treated as an RFE, and departing from the current behavior should be discussed on the wildfly-dev list.



>  CLI Does Not Log History With "--file" and "--command(s)" args
> ---------------------------------------------------------------
>
>                 Key: WFCORE-790
>                 URL: https://issues.jboss.org/browse/WFCORE-790
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha5
>            Reporter: Petr Kremensky
>            Assignee: Alexey Loubyansky
>
> Cli doesn't log commands passed by  "\-\-file" and "\-\-command(s)" arguments.
> https://bugzilla.redhat.com/show_bug.cgi?id=1232890



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 15:58:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 15:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-790) CLI Does Not Log History
 With "--file" and "--command(s)" args
In-Reply-To: <JIRA.12576881.1435835622000@Atlassian.JIRA>
References: <JIRA.12576881.1435835622000@Atlassian.JIRA>
	<JIRA.12576881.1435835622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576881.1435835622000.37085.1442433480463@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-790:
------------------------------------
    Issue Type: Enhancement  (was: Bug)


>  CLI Does Not Log History With "--file" and "--command(s)" args
> ---------------------------------------------------------------
>
>                 Key: WFCORE-790
>                 URL: https://issues.jboss.org/browse/WFCORE-790
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha5
>            Reporter: Petr Kremensky
>            Assignee: Alexey Loubyansky
>
> Cli doesn't log commands passed by  "\-\-file" and "\-\-command(s)" arguments.
> https://bugzilla.redhat.com/show_bug.cgi?id=1232890



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:02:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 16:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-728) backup/download the deployed
	apps
In-Reply-To: <JIRA.12573510.1433235675000@Atlassian.JIRA>
References: <JIRA.12573510.1433235675000@Atlassian.JIRA>
	<JIRA.12573510.1433235675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573510.1433235675000.37089.1442433720215@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-728:
---------------------------------------

    Assignee:     (was: Jason Greene)


> backup/download the deployed apps
> ---------------------------------
>
>                 Key: WFCORE-728
>                 URL: https://issues.jboss.org/browse/WFCORE-728
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Jimmy Pannier
>
> Download/backup deployed archive is not possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:10:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 16:10:00 -0400 (EDT)
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.37129.1442434200219@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5249:
-----------------------------------

This issue is now fixed. [~ctomc]  You can close this issue with the proper fix version now. 

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:13:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 16:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when
 adding large deployment with audit logging enabled
In-Reply-To: <JIRA.12571787.1431651101000@Atlassian.JIRA>
References: <JIRA.12571787.1431651101000@Atlassian.JIRA>
	<JIRA.12571787.1431651101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571787.1431651101000.37157.1442434380303@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-695:
---------------------------------------

    Component/s: CLI
       Assignee: Alexey Loubyansky


[~aloubyansky] I don't think we can/should directly fix this in the audit logging layer; that's just a generic write of the contents of the mgmt op and fixing this would basically involve hard-coding a very specific deviation from the normal handling.

I think the main issue here is the CLI 'deploy' commands are shipping the deployment bytes to the server via base-64 encoded DMR (the "bytes" param to the op) instead of attaching a stream to the op.

I suspect it's done this way because attaching a stream is tricky since you need an Operation object scoped to whatever set of operations need to get run in a single request.

> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-695
>                 URL: https://issues.jboss.org/browse/WFCORE-695
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 1.0.0.CR4
>            Reporter: James Livingston
>            Assignee: Alexey Loubyansky
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
>         at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
>         at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
>         at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:14:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 16:14:00 -0400 (EDT)
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.37173.1442434440412@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5244:
-----------------------------------

[~ctomc] This issue is now fixed and can be closed after you target the proper fix versions etc. 

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:16:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-601) Boot sometimes fails on
 restart when deployments are present in the deployments directory and the
 deployment scanner is in use
In-Reply-To: <JIRA.12566089.1426589689000@Atlassian.JIRA>
References: <JIRA.12566089.1426589689000@Atlassian.JIRA>
	<JIRA.12566089.1426589689000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566089.1426589689000.37190.1442434560280@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-601:
---------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Stuart Douglas)


> Boot sometimes fails on restart when deployments are present in the deployments directory and the deployment scanner is in use
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-601
>                 URL: https://issues.jboss.org/browse/WFCORE-601
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Stuart Douglas
>            Assignee: ehsavoie Hugonnet
>
> I observed this today, looks to be some kind of race in the deployment scanner on boot
> {code}
> 21:52:08,618 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final
> 21:52:10,370 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final
> 21:52:10,440 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting
> 21:52:11,390 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 20) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
> 21:52:11,409 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment mysql-ds.xml
> 21:52:11,413 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment wildfly-ee7.war
> 21:52:11,488 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/48/032d14f289775249a004205c059588ab0f44d4/content
> 21:52:11,504 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/c6/7babde4791697ddc6509fbd43ba1ec25952d47/content
> 21:52:11,506 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "wildfly-ee7.war")]) - failure description: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"wildfly-ee7.war\")]"
> 21:52:11,509 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations"
> 21:52:11,512 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations\""
> 21:52:11,514 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 21:52:11,514 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:17:00 2015
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Wed, 16 Sep 2015 16:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5247)
 wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in
 eclipse
In-Reply-To: <JIRA.12583372.1441090578000@Atlassian.JIRA>
References: <JIRA.12583372.1441090578000@Atlassian.JIRA>
	<JIRA.12583372.1441090578000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583372.1441090578000.37198.1442434620226@Atlassian.JIRA>


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

Rob Stryker commented on WFLY-5247:
-----------------------------------

[~ctomc]  This issue seems to be fixed and can be closed after being targeted properly. 

> wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate in eclipse
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5247
>                 URL: https://issues.jboss.org/browse/WFLY-5247
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>
> wildfly-ejb-multi-server-app-one-ejb quickstart fails to validate. 
> The xml file jboss-ejb3.xml file inside the project has the following content:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
>     JBoss, Home of Professional Open Source
>     Copyright 2013, Red Hat, Inc. and/or its affiliates, and individual
>     contributors by the @authors tag. See the copyright.txt in the
>     distribution for a full listing of individual contributors.
>     Licensed under the Apache License, Version 2.0 (the "License");
>     you may not use this file except in compliance with the License.
>     You may obtain a copy of the License at
>     http://www.apache.org/licenses/LICENSE-2.0
>     Unless required by applicable law or agreed to in writing, software
>     distributed under the License is distributed on an "AS IS" BASIS,
>     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>     See the License for the specific language governing permissions and
>     limitations under the License.
> -->
> <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:s="urn:security"
>     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">
>     <enterprise-beans>
>     </enterprise-beans>
>     <assembly-descriptor>
>     </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> Unfortunately, the element "enterprise-beans" is not allowed to be empty. 
> A solution is to remove the empty "enterprise-beans" element. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:24:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 16:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-527) Embedded server is not
 graceful-shutdown friendly
In-Reply-To: <JIRA.12562148.1422834487000@Atlassian.JIRA>
References: <JIRA.12562148.1422834487000@Atlassian.JIRA>
	<JIRA.12562148.1422834487000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562148.1422834487000.37222.1442435040082@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-527:
------------------------------------
    Labels: offline-cli  (was: )


> Embedded server is not graceful-shutdown friendly
> -------------------------------------------------
>
>                 Key: WFCORE-527
>                 URL: https://issues.jboss.org/browse/WFCORE-527
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Brian Stansberry
>              Labels: offline-cli
>
> The embedded server implements stop by stopping the service container. This is not graceful-shutdown friendly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 16:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-384) Server does wrongly
 reference a list of socket binding groups
In-Reply-To: <JIRA.12473104.1346058118000@Atlassian.JIRA>
References: <JIRA.12473104.1346058118000@Atlassian.JIRA>
	<JIRA.12473104.1346058118000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473104.1346058118000.37283.1442435940165@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-384:
-----------------------------------------

We can't make this a proper singleton (i.e. with an unchangeable address socket-binding-group=standard sockets) without making an incompatible API change, since currently users can pick the name. However, what can be done:

1) Use the WFCORE-365 solution to correctly report the cardinality of the resource definition (max-occurs=1).

2) The add handler can add a step to validate the cardinality. ValidateModelStepHandler could perhaps even do this globally, although I'm reluctant to take the boot overhead cost to do this kind of check for every resource.

> Server does wrongly reference a list of socket binding groups
> -------------------------------------------------------------
>
>                 Key: WFCORE-384
>                 URL: https://issues.jboss.org/browse/WFCORE-384
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Ken Wills
>             Fix For: 3.0.0.Beta1
>
>
> hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups
> [10:59am] hbraun: shouldn't that be a a single socket binding instead?
> [11:00am] emuckenhuber: oh... yeah
> [11:00am] hbraun: maybe it's just the description that's wrong
> [11:00am] emuckenhuber: that sounds similar to the jvm thing we had



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:54:00 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Wed, 16 Sep 2015 16:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-912) LdapExtLoginModule fails
 to load roles when a Custom Principal is specified
In-Reply-To: <JIRA.12475030.1348175635000@Atlassian.JIRA>
References: <JIRA.12475030.1348175635000@Atlassian.JIRA>
	<JIRA.12475030.1348175635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475030.1348175635000.37326.1442436840403@Atlassian.JIRA>


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

Derek Horton moved WFLY-889 to SECURITY-912:
--------------------------------------------

        Project: PicketBox   (was: WildFly)
            Key: SECURITY-912  (was: WFLY-889)
       Workflow: classic default workflow  (was: GIT Pull Request workflow )
    Component/s: JBossSX, Security-SPI
                     (was: Security)


> LdapExtLoginModule fails to load roles when a Custom Principal is specified
> ---------------------------------------------------------------------------
>
>                 Key: SECURITY-912
>                 URL: https://issues.jboss.org/browse/SECURITY-912
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Jess Sightler
>            Assignee: Anil Saldhana
>
> LdapExtLoginModule.addRole(String) calls:
> super.createIdentity(roleName);
> This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
> The callchain is:
> createLdapInitContext->rolesSearch->addRole
> Lines 432 and 433 of LdapExtLoginModule are:
> if (currentTCCL != null)
>             SecurityActions.setContextClassLoader(null);
> This clears the classloader, so the principal class cannot be loaded.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 16:54:00 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Wed, 16 Sep 2015 16:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-912) LdapExtLoginModule fails
 to load roles when a Custom Principal is specified
In-Reply-To: <JIRA.12475030.1348175635000@Atlassian.JIRA>
References: <JIRA.12475030.1348175635000@Atlassian.JIRA>
	<JIRA.12475030.1348175635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475030.1348175635000.37330.1442436840498@Atlassian.JIRA>


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

Derek Horton reassigned SECURITY-912:
-------------------------------------

    Assignee: Derek Horton  (was: Anil Saldhana)


> LdapExtLoginModule fails to load roles when a Custom Principal is specified
> ---------------------------------------------------------------------------
>
>                 Key: SECURITY-912
>                 URL: https://issues.jboss.org/browse/SECURITY-912
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Jess Sightler
>            Assignee: Derek Horton
>
> LdapExtLoginModule.addRole(String) calls:
> super.createIdentity(roleName);
> This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
> The callchain is:
> createLdapInitContext->rolesSearch->addRole
> Lines 432 and 433 of LdapExtLoginModule are:
> if (currentTCCL != null)
>             SecurityActions.setContextClassLoader(null);
> This clears the classloader, so the principal class cannot be loaded.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:21:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 17:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-912) LdapExtLoginModule fails
 to load roles when a Custom Principal is specified
In-Reply-To: <JIRA.12475030.1348175635000@Atlassian.JIRA>
References: <JIRA.12475030.1348175635000@Atlassian.JIRA>
	<JIRA.12475030.1348175635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475030.1348175635000.37409.1442438460363@Atlassian.JIRA>


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

RH Bugzilla Integration updated SECURITY-912:
---------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1263847
        Bugzilla Update: Perform


> LdapExtLoginModule fails to load roles when a Custom Principal is specified
> ---------------------------------------------------------------------------
>
>                 Key: SECURITY-912
>                 URL: https://issues.jboss.org/browse/SECURITY-912
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Jess Sightler
>            Assignee: Derek Horton
>
> LdapExtLoginModule.addRole(String) calls:
> super.createIdentity(roleName);
> This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
> The callchain is:
> createLdapInitContext->rolesSearch->addRole
> Lines 432 and 433 of LdapExtLoginModule are:
> if (currentTCCL != null)
>             SecurityActions.setContextClassLoader(null);
> This clears the classloader, so the principal class cannot be loaded.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:31:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 17:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-912) LdapExtLoginModule fails
 to load roles when a Custom Principal is specified
In-Reply-To: <JIRA.12475030.1348175635000@Atlassian.JIRA>
References: <JIRA.12475030.1348175635000@Atlassian.JIRA>
	<JIRA.12475030.1348175635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475030.1348175635000.37494.1442439060133@Atlassian.JIRA>


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

RH Bugzilla Integration updated SECURITY-912:
---------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1263847, https://bugzilla.redhat.com/show_bug.cgi?id=1263852  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1263847)


> LdapExtLoginModule fails to load roles when a Custom Principal is specified
> ---------------------------------------------------------------------------
>
>                 Key: SECURITY-912
>                 URL: https://issues.jboss.org/browse/SECURITY-912
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Jess Sightler
>            Assignee: Derek Horton
>
> LdapExtLoginModule.addRole(String) calls:
> super.createIdentity(roleName);
> This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
> The callchain is:
> createLdapInitContext->rolesSearch->addRole
> Lines 432 and 433 of LdapExtLoginModule are:
> if (currentTCCL != null)
>             SecurityActions.setContextClassLoader(null);
> This clears the classloader, so the principal class cannot be loaded.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:48:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 17:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3625) Inconsistent deployment
 status when deploy an EJB containing wrong dependencies
In-Reply-To: <JIRA.12546417.1405393124000@Atlassian.JIRA>
References: <JIRA.12546417.1405393124000@Atlassian.JIRA>
	<JIRA.12546417.1405393124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546417.1405393124000.37512.1442440080192@Atlassian.JIRA>


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

Brian Stansberry reassigned WFLY-3625:
--------------------------------------

    Component/s: Web Console
                     (was: Server)
       Assignee:     (was: Jason Greene)


> Inconsistent deployment status when deploy an EJB containing wrong dependencies
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3625
>                 URL: https://issues.jboss.org/browse/WFLY-3625
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>    Affects Versions: 8.1.0.Final
>            Reporter: Lyle Wang
>         Attachments: WFLY-3625.zip
>
>
> On deploying an EJB (in exploded ear) which has wrong @Resource/"lookup" JNDI names, it gives ERROR log. The marker file is changed to "***.ear.failed", but in web console "http://localhost:9990" the deployment is displayed in "Manage Deployments" page and shows deployed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:50:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 17:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3625) Inconsistent deployment
 status when deploy an EJB containing wrong dependencies
In-Reply-To: <JIRA.12546417.1405393124000@Atlassian.JIRA>
References: <JIRA.12546417.1405393124000@Atlassian.JIRA>
	<JIRA.12546417.1405393124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546417.1405393124000.37516.1442440200318@Atlassian.JIRA>


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

Brian Stansberry resolved WFLY-3625.
------------------------------------
    Resolution: Out of Date


In the current WildFly 10 the console shows the deployment with the following info:

Deployment is enabled
Status is FAILED

Plus some other details.

> Inconsistent deployment status when deploy an EJB containing wrong dependencies
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3625
>                 URL: https://issues.jboss.org/browse/WFLY-3625
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>    Affects Versions: 8.1.0.Final
>            Reporter: Lyle Wang
>         Attachments: WFLY-3625.zip
>
>
> On deploying an EJB (in exploded ear) which has wrong @Resource/"lookup" JNDI names, it gives ERROR log. The marker file is changed to "***.ear.failed", but in web console "http://localhost:9990" the deployment is displayed in "Manage Deployments" page and shows deployed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:53:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 17:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1238) Add tests for boot time
 handling of file system deployments
In-Reply-To: <JIRA.12468790.1339669509000@Atlassian.JIRA>
References: <JIRA.12468790.1339669509000@Atlassian.JIRA>
	<JIRA.12468790.1339669509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468790.1339669509000.37535.1442440380664@Atlassian.JIRA>


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

Brian Stansberry resolved WFLY-1238.
------------------------------------
      Assignee:     (was: Jason Greene)
    Resolution: Out of Date


> Add tests for boot time handling of file system deployments
> -----------------------------------------------------------
>
>                 Key: WFLY-1238
>                 URL: https://issues.jboss.org/browse/WFLY-1238
>             Project: WildFly
>          Issue Type: Task
>          Components: Server
>            Reporter: jaikiran pai
>
> Post 7.1.1.Final release, we changed the way the filesystem deployment scanning was done during boot time. The deployment scanning operation now runs as a boot time operation which triggers a one-off scan to deploy the filesystem deployments.
> After this change there have been a few issues with filesystem deployment handling which have been reported in the following JIRAs:
> https://issues.jboss.org/browse/AS7-4583
> https://issues.jboss.org/browse/AS7-4992
> Although those issues have been fixed, we will have to add tests around boot time handling of the filesystem deployment service so that those issues or other similar issues don't happen again.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:56:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 17:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-985) different startup behaviour:
 commandline parameters and jboss.properties files
In-Reply-To: <JIRA.12470945.1343034963000@Atlassian.JIRA>
References: <JIRA.12470945.1343034963000@Atlassian.JIRA>
	<JIRA.12470945.1343034963000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470945.1343034963000.37543.1442440560235@Atlassian.JIRA>


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

Brian Stansberry moved WFLY-929 to WFCORE-985:
----------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-985  (was: WFLY-929)
    Component/s: Domain Management
                     (was: Server)


> different startup behaviour: commandline parameters and jboss.properties files
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-985
>                 URL: https://issues.jboss.org/browse/WFCORE-985
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Gernot P
>            Assignee: Jason Greene
>
> Starting my domain with
> ${JBOSS_HOME}/bin/domain.sh -Djboss.domain.base.dir=/domain1
> the host-controller.log and process-controller.log are written (as expected) to /domain1/log
> But starting my domain with
> ${JBOSS_HOME}/bin/domain.sh --properties=/domain1/jboss.properties
> where /domain1/jboss.properties contains following line
> jboss.domain.base.dir=/domain1
> the host-controller.log and process-controller.log are written to ${JBOSS_HOME}/domain/log
> The same result (logfiles are written to ${JBOSS_HOME}/domain/log) with /domain1/jboss.properties with following two lines:
>   jboss.domain.base.dir=/domain1
>   jboss.domain.log.dir=/domain1/log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:57:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 17:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-985) different startup behaviour:
 commandline parameters and jboss.properties files
In-Reply-To: <JIRA.12470945.1343034963000@Atlassian.JIRA>
References: <JIRA.12470945.1343034963000@Atlassian.JIRA>
	<JIRA.12470945.1343034963000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470945.1343034963000.37551.1442440620190@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-985:
---------------------------------------

    Assignee:     (was: Jason Greene)


> different startup behaviour: commandline parameters and jboss.properties files
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-985
>                 URL: https://issues.jboss.org/browse/WFCORE-985
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Gernot P
>
> Starting my domain with
> ${JBOSS_HOME}/bin/domain.sh -Djboss.domain.base.dir=/domain1
> the host-controller.log and process-controller.log are written (as expected) to /domain1/log
> But starting my domain with
> ${JBOSS_HOME}/bin/domain.sh --properties=/domain1/jboss.properties
> where /domain1/jboss.properties contains following line
> jboss.domain.base.dir=/domain1
> the host-controller.log and process-controller.log are written to ${JBOSS_HOME}/domain/log
> The same result (logfiles are written to ${JBOSS_HOME}/domain/log) with /domain1/jboss.properties with following two lines:
>   jboss.domain.base.dir=/domain1
>   jboss.domain.log.dir=/domain1/log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 17:58:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 17:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-360) HTTP management API section
 in the Admin Guide
In-Reply-To: <JIRA.12441285.1310057093000@Atlassian.JIRA>
References: <JIRA.12441285.1310057093000@Atlassian.JIRA>
	<JIRA.12441285.1310057093000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441285.1310057093000.37558.1442440680212@Atlassian.JIRA>


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

Brian Stansberry resolved WFCORE-360.
-------------------------------------
    Resolution: Done


> HTTP management API section in the Admin Guide
> ----------------------------------------------
>
>                 Key: WFCORE-360
>                 URL: https://issues.jboss.org/browse/WFCORE-360
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>
> We need a technical guide to the HTTP management API.
> The "Management clients" section gives a basic overview. But it should reference a separate section that documents the usage of GET and POST, the URL patterns, the JSON representation of DMR etc.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:00:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-857) A read-resource on a
 subsystem resource of a missing deployment returns a successful completion
In-Reply-To: <JIRA.12580075.1438375200000@Atlassian.JIRA>
References: <JIRA.12580075.1438375200000@Atlassian.JIRA>
	<JIRA.12580075.1438375200000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580075.1438375200000.37564.1442440801049@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-857:
---------------------------------------

    Fix Version/s: 3.0.0.Alpha1
         Assignee:     (was: Brian Stansberry)


> A read-resource on a subsystem resource of a missing deployment returns a successful completion
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-857
>                 URL: https://issues.jboss.org/browse/WFCORE-857
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>             Fix For: 3.0.0.Alpha1
>
>
> Executing the follow operation results in the operation succeeding even though  no deployment exists with the name.
> {code}
> [standalone at localhost:9990 /] /deployment=foo.war/subsystem=*:read-resource
> {
>     "outcome" => "success",
>     "result" => []
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:02:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-316) Slave host does not register
 to DC when starting with --cached-dc and DC is available
In-Reply-To: <JIRA.12463378.1333633267000@Atlassian.JIRA>
References: <JIRA.12463378.1333633267000@Atlassian.JIRA>
	<JIRA.12463378.1333633267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463378.1333633267000.37590.1442440921486@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-316:
------------------------------------
    Issue Type: Enhancement  (was: Bug)


> Slave host does not register to DC when starting with --cached-dc and DC is available
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-316
>                 URL: https://issues.jboss.org/browse/WFCORE-316
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Manel Martinez Gonzalez
>            Assignee: Ken Wills
>
> NOTE: this is related to AS7-4281 (see https://issues.jboss.org/browse/AS7-4281?focusedCommentId=12682058&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12682058 )
> When a slave host is started with --cached-dc option it won't register to Domain Controller although it's available. domain.sh help says "If this host is not the Domain Controller and cannot contact the Domain Controller at boot, boot using a locally cached copy of the domain configuration (see --backup)" and this is not really happening because slave host never contact to DC with --cached-dc



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:04:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-969) unable to deploy
	icescrum_R4_3.1
In-Reply-To: <JIRA.12457749.1327698330000@Atlassian.JIRA>
References: <JIRA.12457749.1327698330000@Atlassian.JIRA>
	<JIRA.12457749.1327698330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457749.1327698330000.37607.1442441040263@Atlassian.JIRA>


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

Brian Stansberry reassigned WFLY-969:
-------------------------------------

    Component/s: Web (Undertow)
                     (was: Server)
       Assignee: Stuart Douglas  (was: Jason Greene)


> unable to deploy icescrum_R4_3.1
> --------------------------------
>
>                 Key: WFLY-969
>                 URL: https://issues.jboss.org/browse/WFLY-969
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>         Environment: Ubuntu 11.10 64 bits
> 12Go DDR3
> java version "1.6.0_23"
> OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
>            Reporter: glopinous glopinous
>            Assignee: Stuart Douglas
>              Labels: icescrum
>
> I use jboss in standalone mode (unzip only, not modified)
> I deploy icescrum_R4_3.1.war, but can't access by url "http://localhost:8080/icescrum_R4_3.1/" (http code 404)
> deply command : 
> [standalone at localhost:9999 /] deploy ../../../tools/icescrum_R4_3.1.war
> Logs : 
> 21:58:16,778 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "icescrum_R4_3.1.war"
> 21:58:20,767 INFO  [org.jboss.web] (MSC service thread 1-8) registering web context: /icescrum_R4_3.1
> 21:58:20,784 INFO  [org.jboss.as.server] (management-handler-threads - 3) JBAS018559: Deployed "icescrum_R4_3.1.war"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:04:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-969) unable to deploy
	icescrum_R4_3.1
In-Reply-To: <JIRA.12457749.1327698330000@Atlassian.JIRA>
References: <JIRA.12457749.1327698330000@Atlassian.JIRA>
	<JIRA.12457749.1327698330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457749.1327698330000.37611.1442441040353@Atlassian.JIRA>


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

Brian Stansberry updated WFLY-969:
----------------------------------
    Component/s: Web (JBoss Web)


> unable to deploy icescrum_R4_3.1
> --------------------------------
>
>                 Key: WFLY-969
>                 URL: https://issues.jboss.org/browse/WFLY-969
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>         Environment: Ubuntu 11.10 64 bits
> 12Go DDR3
> java version "1.6.0_23"
> OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
>            Reporter: glopinous glopinous
>            Assignee: Stuart Douglas
>              Labels: icescrum
>
> I use jboss in standalone mode (unzip only, not modified)
> I deploy icescrum_R4_3.1.war, but can't access by url "http://localhost:8080/icescrum_R4_3.1/" (http code 404)
> deply command : 
> [standalone at localhost:9999 /] deploy ../../../tools/icescrum_R4_3.1.war
> Logs : 
> 21:58:16,778 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "icescrum_R4_3.1.war"
> 21:58:20,767 INFO  [org.jboss.web] (MSC service thread 1-8) registering web context: /icescrum_R4_3.1
> 21:58:20,784 INFO  [org.jboss.as.server] (management-handler-threads - 3) JBAS018559: Deployed "icescrum_R4_3.1.war"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:04:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-969) unable to deploy
	icescrum_R4_3.1
In-Reply-To: <JIRA.12457749.1327698330000@Atlassian.JIRA>
References: <JIRA.12457749.1327698330000@Atlassian.JIRA>
	<JIRA.12457749.1327698330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457749.1327698330000.37615.1442441040463@Atlassian.JIRA>


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

Brian Stansberry reassigned WFLY-969:
-------------------------------------

    Assignee:     (was: Stuart Douglas)


> unable to deploy icescrum_R4_3.1
> --------------------------------
>
>                 Key: WFLY-969
>                 URL: https://issues.jboss.org/browse/WFLY-969
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>         Environment: Ubuntu 11.10 64 bits
> 12Go DDR3
> java version "1.6.0_23"
> OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
>            Reporter: glopinous glopinous
>              Labels: icescrum
>
> I use jboss in standalone mode (unzip only, not modified)
> I deploy icescrum_R4_3.1.war, but can't access by url "http://localhost:8080/icescrum_R4_3.1/" (http code 404)
> deply command : 
> [standalone at localhost:9999 /] deploy ../../../tools/icescrum_R4_3.1.war
> Logs : 
> 21:58:16,778 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "icescrum_R4_3.1.war"
> 21:58:20,767 INFO  [org.jboss.web] (MSC service thread 1-8) registering web context: /icescrum_R4_3.1
> 21:58:20,784 INFO  [org.jboss.as.server] (management-handler-threads - 3) JBAS018559: Deployed "icescrum_R4_3.1.war"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:06:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-969) unable to deploy
	icescrum_R4_3.1
In-Reply-To: <JIRA.12457749.1327698330000@Atlassian.JIRA>
References: <JIRA.12457749.1327698330000@Atlassian.JIRA>
	<JIRA.12457749.1327698330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457749.1327698330000.37618.1442441160156@Atlassian.JIRA>


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

Brian Stansberry resolved WFLY-969.
-----------------------------------
    Resolution: Out of Date


Closing as this is quite old and there isn't enough data to reproduce. Please let us know if you are still having issues using WildFly 10.

> unable to deploy icescrum_R4_3.1
> --------------------------------
>
>                 Key: WFLY-969
>                 URL: https://issues.jboss.org/browse/WFLY-969
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>         Environment: Ubuntu 11.10 64 bits
> 12Go DDR3
> java version "1.6.0_23"
> OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
>            Reporter: glopinous glopinous
>              Labels: icescrum
>
> I use jboss in standalone mode (unzip only, not modified)
> I deploy icescrum_R4_3.1.war, but can't access by url "http://localhost:8080/icescrum_R4_3.1/" (http code 404)
> deply command : 
> [standalone at localhost:9999 /] deploy ../../../tools/icescrum_R4_3.1.war
> Logs : 
> 21:58:16,778 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "icescrum_R4_3.1.war"
> 21:58:20,767 INFO  [org.jboss.web] (MSC service thread 1-8) registering web context: /icescrum_R4_3.1
> 21:58:20,784 INFO  [org.jboss.as.server] (management-handler-threads - 3) JBAS018559: Deployed "icescrum_R4_3.1.war"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:07:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3842) Netty direct buffer detection
 broken due to missing module dependencies
In-Reply-To: <JIRA.12551726.1410362755000@Atlassian.JIRA>
References: <JIRA.12551726.1410362755000@Atlassian.JIRA>
	<JIRA.12551726.1410362755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551726.1410362755000.37623.1442441220202@Atlassian.JIRA>


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

Brian Stansberry reassigned WFLY-3842:
--------------------------------------

    Component/s: JMS
                     (was: Server)
       Assignee: Jeff Mesnil  (was: Jason Greene)


> Netty direct buffer detection broken due to missing module dependencies
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3842
>                 URL: https://issues.jboss.org/browse/WFLY-3842
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
>            Reporter: Seth Miller
>            Assignee: Jeff Mesnil
>
> When deploying Wildfly 8.x, you'll see this in the server.log:
> {code}
> INFO [io.netty.util.internal.PlatformDependent] Your platform does not provide complete low-level API for accessing direct buffers reliably. Unless explicitly requested, heap buffer will always be preferred to av
> oid potential system unstability.
> {code}
> Following this into netty, here:
> https://github.com/netty/netty/blob/master/common/src/main/java/io/netty/util/internal/PlatformDependent.java#L581
> Down to here:
> https://github.com/netty/netty/blob/netty-4.0.15.Final/common/src/main/java/io/netty/util/internal/PlatformDependent0.java#L82
> We need access to sun.misc to see if direct buffers are available.
> Adding sun.misc to the netty module removes the log message, but if we TRACE on io.netty, there is one additional message: 
> {code}
> 2014-09-09 13:58:35,512 FINE [io.netty.util.internal.PlatformDependent] -Dio.netty.noJavassist: false
> 2014-09-09 13:58:35,513 FINE [io.netty.util.internal.PlatformDependent] Javassist: unavailable
> 2014-09-09 13:58:35,513 FINE [io.netty.util.internal.PlatformDependent] You don't have Javassist in your class path or you don't have enough permission to load dynamically generated classes.  Please check the configuration for better performance.
> {code}
> We can provide netty with a depends on Javassist to remove the FINE message about performance.
> Workaround:  alter the module io/netty/main/module.xml to include the following {code}
> <module xmlns="urn:jboss:module:1.3" name="io.netty">
>     <resources>
>         <resource-root path="netty-all-4.0.15.Final.jar"/>
>     </resources>
>     <dependencies>
>         <module name="sun.jdk"/>
>         <module name="org.javassist"/>
>     </dependencies>
> </module>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:21:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212)
 java.lang.StringIndexOutOfBoundsException during deployment of war with
 specific ejb jar descriptor
In-Reply-To: <JIRA.12556556.1415025535000@Atlassian.JIRA>
References: <JIRA.12556556.1415025535000@Atlassian.JIRA>
	<JIRA.12556556.1415025535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556556.1415025535000.37638.1442442060278@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-212:
-----------------------------------------

[~jmesnil] this is failing because HornetQServerResource is trying to create a runtime queue child with an non-null but empty string for its name.

There's a bug in PathElement such that it's not handling this properly, but I'm not sure if there's a bug in the messaging code such that such a PathElement is wanted. I'm reluctant to allow the empty string as a value in a PathElement. 

> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-212
>                 URL: https://issues.jboss.org/browse/WFCORE-212
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Jason Greene
>         Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
>        <activation-config-property>
>           <activation-config-property-name>subscriptionDurability</activation-config-property-name>
>           <activation-config-property-value>Durable</activation-config-property-value>
>         </activation-config-property>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:24:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212)
 java.lang.StringIndexOutOfBoundsException during deployment of war with
 specific ejb jar descriptor
In-Reply-To: <JIRA.12556556.1415025535000@Atlassian.JIRA>
References: <JIRA.12556556.1415025535000@Atlassian.JIRA>
	<JIRA.12556556.1415025535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556556.1415025535000.37642.1442442240183@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-212:
------------------------------------
    Component/s: Domain Management
                     (was: Server)


> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-212
>                 URL: https://issues.jboss.org/browse/WFCORE-212
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Jason Greene
>         Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
>        <activation-config-property>
>           <activation-config-property-name>subscriptionDurability</activation-config-property-name>
>           <activation-config-property-value>Durable</activation-config-property-value>
>         </activation-config-property>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:24:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212)
 java.lang.StringIndexOutOfBoundsException during deployment of war with
 specific ejb jar descriptor
In-Reply-To: <JIRA.12556556.1415025535000@Atlassian.JIRA>
References: <JIRA.12556556.1415025535000@Atlassian.JIRA>
	<JIRA.12556556.1415025535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556556.1415025535000.37646.1442442240248@Atlassian.JIRA>


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

Brian Stansberry reassigned WFCORE-212:
---------------------------------------

    Assignee: Brian Stansberry  (was: Jason Greene)


> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-212
>                 URL: https://issues.jboss.org/browse/WFCORE-212
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Brian Stansberry
>         Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
>        <activation-config-property>
>           <activation-config-property-name>subscriptionDurability</activation-config-property-name>
>           <activation-config-property-value>Durable</activation-config-property-value>
>         </activation-config-property>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:25:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3498) "reload-required" set when
 adding mail-session via jboss-cli
In-Reply-To: <JIRA.12543807.1402696832000@Atlassian.JIRA>
References: <JIRA.12543807.1402696832000@Atlassian.JIRA>
	<JIRA.12543807.1402696832000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543807.1402696832000.37652.1442442300288@Atlassian.JIRA>


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

Brian Stansberry reassigned WFLY-3498:
--------------------------------------

    Component/s: Mail
                     (was: Server)
       Assignee: Tomaz Cerar  (was: Jason Greene)


> "reload-required" set when adding mail-session via jboss-cli
> ------------------------------------------------------------
>
>                 Key: WFLY-3498
>                 URL: https://issues.jboss.org/browse/WFLY-3498
>             Project: WildFly
>          Issue Type: Bug
>          Components: Mail
>    Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Tomaz Cerar
>
> When adding a mail-session using jboss-cli the server state changes to "reload-required" although the configured Mail is usable without reload.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 18:30:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 16 Sep 2015 18:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3693) Module org.jboss.as.version
 contains 2 identical jar files
In-Reply-To: <JIRA.12547958.1406735788000@Atlassian.JIRA>
References: <JIRA.12547958.1406735788000@Atlassian.JIRA>
	<JIRA.12547958.1406735788000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547958.1406735788000.37661.1442442600255@Atlassian.JIRA>


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

Brian Stansberry resolved WFLY-3693.
------------------------------------
      Assignee:     (was: Paul Gier)
    Resolution: Out of Date


I don't see this problem in the 9.0.0.Final dist. My guess is it was some issue in the way 9.0.0.Alpha1 was prepared.

> Module org.jboss.as.version contains 2 identical jar files
> ----------------------------------------------------------
>
>                 Key: WFLY-3693
>                 URL: https://issues.jboss.org/browse/WFLY-3693
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System, Server
>    Affects Versions: 9.0.0.Alpha1
>         Environment: WildFly 9.0 build from current github-sources as of today.
> Solaris SPARC 10, Oracle JDK 1.7.0_65
>            Reporter: Frank Langelage
>            Priority: Minor
>
> Module org.jboss.as.version contains 2 identical jar files 
> -rw-r--r--   1 jboss    informix   14111 Jul 30 13:21 jboss-as-version-9.0.0.Alpha1-SNAPSHOT.jar
> -rw-r--r--   1 jboss    informix   14111 Jul 30 13:21 wildfly-version-1.0.0.Alpha3.jar          
> As only wildfly-version-1.0.0.Alpha3.jar is referenced in module.xml the jboss-as-version-9.0.0.Alpha1-SNAPSHOT.jar seems to be a relict from the past.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 20:51:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 16 Sep 2015 20:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5353) Unable to set resolve-hosts
	for access-log
In-Reply-To: <JIRA.12585103.1442406697000@Atlassian.JIRA>
References: <JIRA.12585103.1442406697000@Atlassian.JIRA>
	<JIRA.12585103.1442406697000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585103.1442406697000.37739.1442451060192@Atlassian.JIRA>


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

Stuart Douglas commented on WFLY-5353:
--------------------------------------

I am updating Undertow so %h will print the host address if it has been resolved. Do we actually need this setting on the access log? I would think that the setting on the connector is enough.

> Unable to set resolve-hosts for access-log
> ------------------------------------------
>
>                 Key: WFLY-5353
>                 URL: https://issues.jboss.org/browse/WFLY-5353
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> In previous versions of EAP (Web subsystem) there was possible to enable resolving hosts for access logging. This is not possible to enable with Undertow.
> Steps for enabling in JBoss Web:
> This was accomplished by setting {{resolve-hosts}} attribute of access-log to {{true}} ({{/subsystem=web/virtual-server=default-host/configuration=access-log:add(resolve-hosts=true)}}) and enabling lookups for connector ({{/subsystem=web/connector=http:write-attribute(name=enable-lookups, value=true)}}).
> In Undertow subsystem there is only possible to enable resolving peer address ({{/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=resolve-peer-address, value=true)}}), which doesn't have by itself any impact on output in access-log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 21:16:02 2015
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Wed, 16 Sep 2015 21:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5029) Reintroduce EJB, JMS,
 JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
In-Reply-To: <JIRA.12579802.1438189664000@Atlassian.JIRA>
References: <JIRA.12579802.1438189664000@Atlassian.JIRA>
	<JIRA.12579802.1438189664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579802.1438189664000.37756.1442452562646@Atlassian.JIRA>


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

Bilge Ozpeynirci updated WFLY-5029:
-----------------------------------
    Summary: Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer  (was: Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability)


> Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5029
>                 URL: https://issues.jboss.org/browse/WFLY-5029
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Bilge Ozpeynirci
>            Assignee: Jason Greene
>
> Ability to run EJB, JMS, JNDI over HTTP/HTTPS which was possible in earlier JBoss AS/EAP 5 & 4.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 21:17:00 2015
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Wed, 16 Sep 2015 21:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5029) Reintroduce EJB, JMS,
 JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
In-Reply-To: <JIRA.12579802.1438189664000@Atlassian.JIRA>
References: <JIRA.12579802.1438189664000@Atlassian.JIRA>
	<JIRA.12579802.1438189664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579802.1438189664000.37759.1442452620100@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bilge Ozpeynirci updated WFLY-5029:
-----------------------------------
    Component/s: EJB
                 Web (Undertow)


> Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5029
>                 URL: https://issues.jboss.org/browse/WFLY-5029
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Server, Web (Undertow)
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Bilge Ozpeynirci
>            Assignee: Jason Greene
>
> Ability to run EJB, JMS, JNDI over HTTP/HTTPS which was possible in earlier JBoss AS/EAP 5 & 4.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:55:04 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-905) Add protection of our
 GSSCredential added by the KerberosLoginModule
In-Reply-To: <JIRA.12582209.1440171736000@Atlassian.JIRA>
References: <JIRA.12582209.1440171736000@Atlassian.JIRA>
	<JIRA.12582209.1440171736000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582209.1440171736000.37831.1442458504463@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109690#comment-13109690 ] 

RH Bugzilla Integration commented on SECURITY-905:
--------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1097276|https://bugzilla.redhat.com/show_bug.cgi?id=1097276] from MODIFIED to ON_QA

> Add protection of our GSSCredential added by the KerberosLoginModule
> --------------------------------------------------------------------
>
>                 Key: SECURITY-905
>                 URL: https://issues.jboss.org/browse/SECURITY-905
>             Project: PicketBox 
>          Issue Type: Task
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_8_Beta1
>
>
> GSSManager implementation can have an optimisation that attempts to obtain the GSSCredential from the private credentials in the Subject, in some situations such as JDBC drivers this can mean that a driver gets direct access to the credential we are supposed to be managing the lifecycle of.
> The optimisation is based on checking if it is an instance of GSSCredentialImpl - if not then GSSManager creates a new instance.
> This Jira issue is to wrap the instance we place in the Subject to prevent the optimisation kicking in.  This then means code using the credential such as a JDBC driver is free to do what it wants with it's own credential without impacting on ours.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:00 -0400 (EDT)
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.37857.1442458560893@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109695#comment-13109695 ] 

RH Bugzilla Integration commented on WFLY-4625:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1243553|https://bugzilla.redhat.com/show_bug.cgi?id=1243553] from MODIFIED to ON_QA

> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:01 -0400 (EDT)
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.37876.1442458561439@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109701#comment-13109701 ] 

RH Bugzilla Integration commented on WFLY-4876:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1240537|https://bugzilla.redhat.com/show_bug.cgi?id=1240537] from MODIFIED to ON_QA

> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:02 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-855) Intermittent Disconnection
 from CLI After Reload in domain mode
In-Reply-To: <JIRA.12580049.1438354335000@Atlassian.JIRA>
References: <JIRA.12580049.1438354335000@Atlassian.JIRA>
	<JIRA.12580049.1438354335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580049.1438354335000.37883.1442458562229@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109703#comment-13109703 ] 

RH Bugzilla Integration commented on WFCORE-855:
------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1249031|https://bugzilla.redhat.com/show_bug.cgi?id=1249031] from MODIFIED to ON_QA

> Intermittent Disconnection from CLI After Reload in domain mode
> ---------------------------------------------------------------
>
>                 Key: WFCORE-855
>                 URL: https://issues.jboss.org/browse/WFCORE-855
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Joe Wertz
>            Assignee: Joe Wertz
>             Fix For: 2.0.0.Alpha13
>
>   Original Estimate: 3 minutes
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>
> Description of problem:
>  CLI scripts for management of managed domain 
> Version-Release number of selected component (if applicable):
>  6.4.3.CP.CR1
> How reproducible:
>  Always
> Steps to Reproduce:
> Use CLI script:
> :read-attribute(name=process-type)
> reload --host=master
> :read-attribute(name=process-type)
> or commands option for script
> Actual results:
> 6.4.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
>     "outcome" => "success",
>     "result" => "Domain Controller"
> }
> Failed to establish connection in 6025ms
> Expected results:
> 6.3.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
>     "outcome" => "success",
>     "result" => "Domain Controller"
> }
> {
>     "outcome" => "success",
>     "result" => "Domain Controller"
> }
> Additional info:
>  - Follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1232933
>  - using --timeout doesn't workaround the problem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:02 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-285) cli tab completion gets
 confused by double slash
In-Reply-To: <JIRA.12557423.1415975102000@Atlassian.JIRA>
References: <JIRA.12557423.1415975102000@Atlassian.JIRA>
	<JIRA.12557423.1415975102000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557423.1415975102000.37888.1442458562538@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109704#comment-13109704 ] 

RH Bugzilla Integration commented on WFCORE-285:
------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1164277|https://bugzilla.redhat.com/show_bug.cgi?id=1164277] from MODIFIED to ON_QA

> cli tab completion gets confused by double slash
> ------------------------------------------------
>
>                 Key: WFCORE-285
>                 URL: https://issues.jboss.org/browse/WFCORE-285
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 1.0.0.Alpha13
>            Reporter: Tom Fonteyne
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>             Fix For: 1.0.0.Alpha14
>
>
> Using two slashes in a CLI path and hitting TAB confuses the auto-completion



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:02 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4942) KeyAffinityService race
 condition on view change
In-Reply-To: <JIRA.12578289.1437053811000@Atlassian.JIRA>
References: <JIRA.12578289.1437053811000@Atlassian.JIRA>
	<JIRA.12578289.1437053811000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578289.1437053811000.37892.1442458562661@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109705#comment-13109705 ] 

RH Bugzilla Integration commented on WFLY-4942:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1233968|https://bugzilla.redhat.com/show_bug.cgi?id=1233968] from MODIFIED to ON_QA

> KeyAffinityService race condition on view change
> ------------------------------------------------
>
>                 Key: WFLY-4942
>                 URL: https://issues.jboss.org/browse/WFLY-4942
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Bartosz Baranowski
>            Assignee: Jason Greene
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:04 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4423) ClassNotFoundException:
 org.jboss.naming.remote.client.InitialContextFactory
In-Reply-To: <JIRA.12565707.1426177059000@Atlassian.JIRA>
References: <JIRA.12565707.1426177059000@Atlassian.JIRA>
	<JIRA.12565707.1426177059000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565707.1426177059000.37902.1442458564700@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109707#comment-13109707 ] 

RH Bugzilla Integration commented on WFLY-4423:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1201358|https://bugzilla.redhat.com/show_bug.cgi?id=1201358] from MODIFIED to ON_QA

> ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-4423
>                 URL: https://issues.jboss.org/browse/WFLY-4423
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 9.0.0.Beta1
>
>
> To reproduce this issue follow the steps:
>  - setup JMS bridge between two WildFly instances
>  - once JMS bridge is running, login into jboss-cli and stop the bridge
>  - restart the bridge fro jboss-cli
> The following exception appears in the serve log file.
> 10:12:59,414 INFO  [org.hornetq.jms.server] (pool-9-thread-1) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 60,000 ms
> 10:13:59,416 WARN  [org.hornetq.jms.server] (pool-9-thread-1) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:126)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_75]
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_75]
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_75]
> 	at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_75]
> 	at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_75]
> 	at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55)
> 	at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1236)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1474)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2200(JMSBridgeImpl.java:79)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2082)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_75]
> 	at java.lang.Class.forName(Class.java:274) [rt.jar:1.7.0_75]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:121)
> 	... 17 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:04 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-499) System properties are broken
 in domain mode
In-Reply-To: <JIRA.12560803.1421114086000@Atlassian.JIRA>
References: <JIRA.12560803.1421114086000@Atlassian.JIRA>
	<JIRA.12560803.1421114086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560803.1421114086000.37907.1442458564844@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109708#comment-13109708 ] 

RH Bugzilla Integration commented on WFCORE-499:
------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1257301|https://bugzilla.redhat.com/show_bug.cgi?id=1257301] from MODIFIED to ON_QA

> System properties are broken in domain mode
> -------------------------------------------
>
>                 Key: WFCORE-499
>                 URL: https://issues.jboss.org/browse/WFCORE-499
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha15
>            Reporter: Stuart Douglas
>            Assignee: ehsavoie Hugonnet
>             Fix For: 1.0.0.Alpha17
>
>
> There seems to be some weirdness in how system properties are being propagated to domain mode servers, and in many cases they are not being applied. 
> This appears to be an issue with the boot time handling of system properties.
> The only way I could get the property to be applied was to start the server first, then add the property using boot-time=false, although even in this case the property will disappear if the domain is restarted or the server is reloaded. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 22:56:06 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Sep 2015 22:56:06 -0400 (EDT)
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.37917.1442458566351@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109710#comment-13109710 ] 

RH Bugzilla Integration commented on WFLY-5221:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1257612|https://bugzilla.redhat.com/show_bug.cgi?id=1257612] from MODIFIED to ON_QA

> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 23:03:00 2015
From: issues at jboss.org (sam dai (JIRA))
Date: Wed, 16 Sep 2015 23:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-918) Janino java compiler issue
In-Reply-To: <JIRA.12585177.1442458941000@Atlassian.JIRA>
References: <JIRA.12585177.1442458941000@Atlassian.JIRA>
	<JIRA.12585177.1442458941234@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585177.1442458941000.37919.1442458980138@Atlassian.JIRA>

sam dai created DROOLS-918:
------------------------------

             Summary: Janino java compiler issue
                 Key: DROOLS-918
                 URL: https://issues.jboss.org/browse/DROOLS-918
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.2.0.Final
            Reporter: sam dai
            Assignee: Mario Fusco


Recently I upgraded drools from version 6.0.0 Final to version 6.2.0 Final, I found some bpm process can't be deployed, the error message is as below.
{color:#d04437}java.lang.IllegalArgumentException: Errors while parsing knowledge base + errors added Unable to generate action invoker. Unknown variable or type "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687"
A method named "action1" is not declared in any enclosing class nor any supertype, nor through a static import
Expression "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687" is not an rvalue{color}

The java compiler is "JANINO" by setting the value of system property "drools.dialect.java.compiler" as "JANINO".  If I use ECLIPSE java compiler, will not have this issue. I debugged the code, found code of line 82 of org.drools.compiler.rule.builder.dialect.DialectUtil.java is changed from
{color:#205081}final String newName = prefix + "_" + NON_ALPHA_REGEX.matcher(name).replaceAll("_");{color}
to 
{color:#205081}final String newName = prefix + "_" + normalizeRuleName( name );{color}
If I changed it back, bpm process can be deployed successfully.
Then I did more testing. for a name "org.drools.bpmn2.fc1291c5-c25c-4c6b-aba3-76efdcd16136 + 2014-03-07 13:06:29 -0800", 
if I use script "normalizeRuleName( name )", the value will be "org$u46$drools$u46$bpmn2$u46$fc1291c5$u45$c25c$u45$4c6b$u45$aba3$u45$76efdcd16136_$u43$_2014$u45$03$u45$07_13$u58$06$u58$29_$u45$0800", 
if use script "NON_ALPHA_REGEX.matcher(name).replaceAll("_");", the value will be 
NON_ALPHA_REGEX.matcher(name).replaceAll("_");

So I wonder if this is a bug or I missed some configuration.









--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 16 23:04:00 2015
From: issues at jboss.org (sam dai (JIRA))
Date: Wed, 16 Sep 2015 23:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-918) Janino java compiler issue
In-Reply-To: <JIRA.12585177.1442458941000@Atlassian.JIRA>
References: <JIRA.12585177.1442458941000@Atlassian.JIRA>
	<JIRA.12585177.1442458941000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585177.1442458941000.37924.1442459040235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

sam dai updated DROOLS-918:
---------------------------
    Description: 
Recently I upgraded drools from version 6.0.0 Final to version 6.2.0 Final, I found some bpm process can't be deployed, the error message is as below.
{color:#d04437}java.lang.IllegalArgumentException: Errors while parsing knowledge base + errors added Unable to generate action invoker. Unknown variable or type "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687"
A method named "action1" is not declared in any enclosing class nor any supertype, nor through a static import
Expression "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687" is not an rvalue{color}

The java compiler is "JANINO" by setting the value of system property "drools.dialect.java.compiler" as "JANINO".  If I use ECLIPSE java compiler, will not have this issue. I debugged the code, found code of line 82 of org.drools.compiler.rule.builder.dialect.DialectUtil.java is changed from
{color:#205081}final String newName = prefix + "_" + NON_ALPHA_REGEX.matcher(name).replaceAll("_");{color}
to 
{color:#205081}final String newName = prefix + "_" + normalizeRuleName( name );{color}
If I changed it back, bpm process can be deployed successfully.
Then I did more testing. for a name "org.drools.bpmn2.fc1291c5-c25c-4c6b-aba3-76efdcd16136 + 2014-03-07 13:06:29 -0800", 
if I use script "normalizeRuleName( name )", the value will be "org$u46$drools$u46$bpmn2$u46$fc1291c5$u45$c25c$u45$4c6b$u45$aba3$u45$76efdcd16136_$u43$_2014$u45$03$u45$07_13$u58$06$u58$29_$u45$0800", 
if use script "NON_ALPHA_REGEX.matcher(name).replaceAll("_");", the value will be 
"org_drools_bpmn2_fc1291c5_c25c_4c6b_aba3_76efdcd16136___2014_03_07_13_06_29__0800"

So I wonder if this is a bug or I missed some configuration.







  was:
Recently I upgraded drools from version 6.0.0 Final to version 6.2.0 Final, I found some bpm process can't be deployed, the error message is as below.
{color:#d04437}java.lang.IllegalArgumentException: Errors while parsing knowledge base + errors added Unable to generate action invoker. Unknown variable or type "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687"
A method named "action1" is not declared in any enclosing class nor any supertype, nor through a static import
Expression "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687" is not an rvalue{color}

The java compiler is "JANINO" by setting the value of system property "drools.dialect.java.compiler" as "JANINO".  If I use ECLIPSE java compiler, will not have this issue. I debugged the code, found code of line 82 of org.drools.compiler.rule.builder.dialect.DialectUtil.java is changed from
{color:#205081}final String newName = prefix + "_" + NON_ALPHA_REGEX.matcher(name).replaceAll("_");{color}
to 
{color:#205081}final String newName = prefix + "_" + normalizeRuleName( name );{color}
If I changed it back, bpm process can be deployed successfully.
Then I did more testing. for a name "org.drools.bpmn2.fc1291c5-c25c-4c6b-aba3-76efdcd16136 + 2014-03-07 13:06:29 -0800", 
if I use script "normalizeRuleName( name )", the value will be "org$u46$drools$u46$bpmn2$u46$fc1291c5$u45$c25c$u45$4c6b$u45$aba3$u45$76efdcd16136_$u43$_2014$u45$03$u45$07_13$u58$06$u58$29_$u45$0800", 
if use script "NON_ALPHA_REGEX.matcher(name).replaceAll("_");", the value will be 
NON_ALPHA_REGEX.matcher(name).replaceAll("_");

So I wonder if this is a bug or I missed some configuration.









> Janino java compiler issue
> --------------------------
>
>                 Key: DROOLS-918
>                 URL: https://issues.jboss.org/browse/DROOLS-918
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.2.0.Final
>            Reporter: sam dai
>            Assignee: Mario Fusco
>
> Recently I upgraded drools from version 6.0.0 Final to version 6.2.0 Final, I found some bpm process can't be deployed, the error message is as below.
> {color:#d04437}java.lang.IllegalArgumentException: Errors while parsing knowledge base + errors added Unable to generate action invoker. Unknown variable or type "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687"
> A method named "action1" is not declared in any enclosing class nor any supertype, nor through a static import
> Expression "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687" is not an rvalue{color}
> The java compiler is "JANINO" by setting the value of system property "drools.dialect.java.compiler" as "JANINO".  If I use ECLIPSE java compiler, will not have this issue. I debugged the code, found code of line 82 of org.drools.compiler.rule.builder.dialect.DialectUtil.java is changed from
> {color:#205081}final String newName = prefix + "_" + NON_ALPHA_REGEX.matcher(name).replaceAll("_");{color}
> to 
> {color:#205081}final String newName = prefix + "_" + normalizeRuleName( name );{color}
> If I changed it back, bpm process can be deployed successfully.
> Then I did more testing. for a name "org.drools.bpmn2.fc1291c5-c25c-4c6b-aba3-76efdcd16136 + 2014-03-07 13:06:29 -0800", 
> if I use script "normalizeRuleName( name )", the value will be "org$u46$drools$u46$bpmn2$u46$fc1291c5$u45$c25c$u45$4c6b$u45$aba3$u45$76efdcd16136_$u43$_2014$u45$03$u45$07_13$u58$06$u58$29_$u45$0800", 
> if use script "NON_ALPHA_REGEX.matcher(name).replaceAll("_");", the value will be 
> "org_drools_bpmn2_fc1291c5_c25c_4c6b_aba3_76efdcd16136___2014_03_07_13_06_29__0800"
> So I wonder if this is a bug or I missed some configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 00:04:00 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Thu, 17 Sep 2015 00:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.37943.1442462640306@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109714#comment-13109714 ] 

?? ? commented on DROOLS-880:
-----------------------------

Edson Please, response this issue. 
Thank you a lot.

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 17 01:43:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4255) Allow Arquillian to specify a
 timeout value for the WildFly clean shutdown mechanism when shutting down a
 server
In-Reply-To: <JIRA.12561011.1421343439000@Atlassian.JIRA>
References: <JIRA.12561011.1421343439000@Atlassian.JIRA>
	<JIRA.12561011.1421343439000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561011.1421343439000.38017.1442468580100@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109728#comment-13109728 ] 

Jason Greene commented on WFLY-4255:
------------------------------------

Can this be resolved or is there still other pending PRs for it?

> Allow Arquillian to specify a timeout value for the WildFly clean shutdown mechanism when shutting down a server
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4255
>                 URL: https://issues.jboss.org/browse/WFLY-4255
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Radoslav Husar
>
> WildFly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete:
> {code}
> [standalone at localhost:9990 /] :shutdown(timeout=5)
> {"outcome" => "success"}
> {code}
> Provide access to this feature from an Arquillian test case  so that test cases may test with or without clean shutdown enabled.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:47:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:47:00 -0400 (EDT)
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.38020.1442468820169@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5246:
-------------------------------
    Fix Version/s: 10.0.0.CR1


> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:47:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:47:00 -0400 (EDT)
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.38024.1442468820250@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5196:
-------------------------------
    Fix Version/s: 10.0.0.CR1


> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix
 org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
 failure
In-Reply-To: <JIRA.12584552.1441887103000@Atlassian.JIRA>
References: <JIRA.12584552.1441887103000@Atlassian.JIRA>
	<JIRA.12584552.1441887103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584552.1441887103000.38027.1442469068352@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5319:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5319
>                 URL: https://issues.jboss.org/browse/WFLY-5319
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR2
>
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.38037.1442469068698@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5290:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 17 01:51:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5252) Fix MDB20TestCase
In-Reply-To: <JIRA.12583412.1441101182000@Atlassian.JIRA>
References: <JIRA.12583412.1441101182000@Atlassian.JIRA>
	<JIRA.12583412.1441101182000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583412.1441101182000.38040.1442469068758@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5252:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Fix MDB20TestCase
> -----------------
>
>                 Key: WFLY-5252
>                 URL: https://issues.jboss.org/browse/WFLY-5252
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Jeff Mesnil
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> The MDB20TestCase is failing often on our test suite with the error:
> {noformat}
> java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueB]
>     at org.junit.Assert.fail(Assert.java:88)
>     at org.junit.Assert.assertTrue(Assert.java:41)
>     at org.junit.Assert.assertNotNull(Assert.java:621)
>     at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:118)
> {noformat}
> From the logs, only 1 of the MDB receives the message sent to the topic.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5194) Restore the original legacy
 configs for use in ParseAndMarshalModelsTestCase
In-Reply-To: <JIRA.12582395.1440466809000@Atlassian.JIRA>
References: <JIRA.12582395.1440466809000@Atlassian.JIRA>
	<JIRA.12582395.1440466809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582395.1440466809000.38043.1442469068820@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5194:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Restore the original legacy configs for use in ParseAndMarshalModelsTestCase
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5194
>                 URL: https://issues.jboss.org/browse/WFLY-5194
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> The configs currently used in ParseAndMarshalModelsTestCase are edited variants, with legacy subsystems no longer supported removed. But that removal should no longer be necessary, since the tests use --admin-only mode and we have committed to support these subsystems in --admin-only. So we should restore the missing bits to have a more accurate test that legacy configs will work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4966) Make sure Weld work fine
 outside the full feature pack
In-Reply-To: <JIRA.12578599.1437399937000@Atlassian.JIRA>
References: <JIRA.12578599.1437399937000@Atlassian.JIRA>
	<JIRA.12578599.1437399937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578599.1437399937000.38046.1442469068956@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4966:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Make sure Weld work fine outside the full feature pack
> ------------------------------------------------------
>
>                 Key: WFLY-4966
>                 URL: https://issues.jboss.org/browse/WFLY-4966
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>             Fix For: 10.0.0.CR2
>
>
> Review subsystem's dependencies and make them optional if appropriate. 
> http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004202.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4934) Make use of the new
 capabilities API in mod_cluster extension
In-Reply-To: <JIRA.12578224.1437000134000@Atlassian.JIRA>
References: <JIRA.12578224.1437000134000@Atlassian.JIRA>
	<JIRA.12578224.1437000134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578224.1437000134000.38049.1442469069012@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4934:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Make use of the new capabilities API in mod_cluster extension
> -------------------------------------------------------------
>
>                 Key: WFLY-4934
>                 URL: https://issues.jboss.org/browse/WFLY-4934
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4872) Add the Elytron subsystem to
 the feature packs
In-Reply-To: <JIRA.12577134.1436206186000@Atlassian.JIRA>
References: <JIRA.12577134.1436206186000@Atlassian.JIRA>
	<JIRA.12577134.1436206186000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577134.1436206186000.38053.1442469069094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4872:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add the Elytron subsystem to the feature packs
> ----------------------------------------------
>
>                 Key: WFLY-4872
>                 URL: https://issues.jboss.org/browse/WFLY-4872
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Build System
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4664) Enable Garbage Collection
 Logging by Default - missing feature from EAP6
In-Reply-To: <JIRA.12572553.1432537333000@Atlassian.JIRA>
References: <JIRA.12572553.1432537333000@Atlassian.JIRA>
	<JIRA.12572553.1432537333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572553.1432537333000.38058.1442469069202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4664:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Enable Garbage Collection Logging by Default - missing feature from EAP6
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4664
>                 URL: https://issues.jboss.org/browse/WFLY-4664
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>            Priority: Optional
>             Fix For: 10.0.0.CR2
>
>
> Description of problem:
> GC logging java opts are not passed to standalone server
> Steps to Reproduce:
>  1. Start the standalone server (on windows or linux) and observe the console logs.
> Actual results:
> JAVA_OPTS: -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> Expected results:
> JAVA_OPTS:  -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -verbose:gc -Xloggc:"$JBOSS_LOG_DIR/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading
> Additional info:
>    - EAP6 jira: https://issues.jboss.org/browse/EAP6-121
>    - EAP6-121 feature is commented in standalone.sh and standalone.bat
>    - these OPTS are missing: -verbose:gc -Xloggc:"$JBOSS_LOG_DIR/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4641) Restore javadoc generation to
 testsuite/shared
In-Reply-To: <JIRA.12571892.1431911412000@Atlassian.JIRA>
References: <JIRA.12571892.1431911412000@Atlassian.JIRA>
	<JIRA.12571892.1431911412000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571892.1431911412000.38062.1442469069428@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4641:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Restore javadoc generation to testsuite/shared
> ----------------------------------------------
>
>                 Key: WFLY-4641
>                 URL: https://issues.jboss.org/browse/WFLY-4641
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> I'm disabling the javadoc plugin for testsuite/shared, as it's failing when I try and deploy a release. This task is to look into re-enabling it.
> Failure was:
> {code}
> [ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot be cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> [ERROR] at com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
> [ERROR] at com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
> [ERROR] at com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
> [ERROR] at com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
> [ERROR] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
> [ERROR] at com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
> [ERROR] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:497)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
> [ERROR] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:192)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
> [ERROR] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
> [ERROR] at com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:497)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
> [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:219)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:205)
> [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:64)
> [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:54)
> [ERROR] javadoc: error - java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot be cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> [ERROR] 
> [ERROR] Command line was: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4608) Omit no-op transaction if
 lifecycle method is missing
In-Reply-To: <JIRA.12571010.1431004453000@Atlassian.JIRA>
References: <JIRA.12571010.1431004453000@Atlassian.JIRA>
	<JIRA.12571010.1431004453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571010.1431004453000.38068.1442469069547@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4608:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Omit no-op transaction if lifecycle method is missing
> -----------------------------------------------------
>
>                 Key: WFLY-4608
>                 URL: https://issues.jboss.org/browse/WFLY-4608
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.CR1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 10.0.0.CR2
>
>
> LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4588) Elytron Integration
In-Reply-To: <JIRA.12570716.1430827075000@Atlassian.JIRA>
References: <JIRA.12570716.1430827075000@Atlassian.JIRA>
	<JIRA.12570716.1430827075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570716.1430827075000.38072.1442469069629@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4588:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Elytron Integration
> -------------------
>
>                 Key: WFLY-4588
>                 URL: https://issues.jboss.org/browse/WFLY-4588
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> Building on WFCORE-673 this is the top level task to cover integration in WildFly
> The majority should be building on top of the work in core but there will be some WildFly specifics to consider.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4582) Use Elytron for Java EE
	security
In-Reply-To: <JIRA.12570632.1430755042000@Atlassian.JIRA>
References: <JIRA.12570632.1430755042000@Atlassian.JIRA>
	<JIRA.12570632.1430755042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570632.1430755042000.38076.1442469069752@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4582:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Use Elytron for Java EE security
> --------------------------------
>
>                 Key: WFLY-4582
>                 URL: https://issues.jboss.org/browse/WFLY-4582
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>             Fix For: 10.0.0.CR2
>
>
> Master issue for converting WildFly's Java EE layer to use Elytron for all security functions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails
 on Ubuntu 15.04
In-Reply-To: <JIRA.12570141.1430251970000@Atlassian.JIRA>
References: <JIRA.12570141.1430251970000@Atlassian.JIRA>
	<JIRA.12570141.1430251970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570141.1430251970000.38081.1442469069866@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4570:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> wildfly-init-debian.sh fails on Ubuntu 15.04
> --------------------------------------------
>
>                 Key: WFLY-4570
>                 URL: https://issues.jboss.org/browse/WFLY-4570
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Beta2, 9.0.0.CR1
>         Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine.  Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is:
> Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory.
> Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4528) Product to Project Schema and
	Model Sync
In-Reply-To: <JIRA.12568718.1429281553000@Atlassian.JIRA>
References: <JIRA.12568718.1429281553000@Atlassian.JIRA>
	<JIRA.12568718.1429281553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568718.1429281553000.38085.1442469069942@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4528:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Product to Project Schema and Model Sync
> ----------------------------------------
>
>                 Key: WFLY-4528
>                 URL: https://issues.jboss.org/browse/WFLY-4528
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> Periodic sync of EAP schemas with WildFly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4515) Fix clustering transformers
 and reenable in mixed-domain tests
In-Reply-To: <JIRA.12568394.1429024821000@Atlassian.JIRA>
References: <JIRA.12568394.1429024821000@Atlassian.JIRA>
	<JIRA.12568394.1429024821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568394.1429024821000.38091.1442469070072@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4515:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
>                 Key: WFLY-4515
>                 URL: https://issues.jboss.org/browse/WFLY-4515
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Kabir Khan
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests. 
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> 	mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
>    ("profile" => "full-ha"),
>    ("subsystem" => "infinispan"),
>    ("cache-container" => "server"),
>    ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> 	/subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ThreadsAttributesWriteHandler.java#L61 so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4416) Cannot obtain
 DOMImplementationRegistry instance
In-Reply-To: <JIRA.12565354.1425984357000@Atlassian.JIRA>
References: <JIRA.12565354.1425984357000@Atlassian.JIRA>
	<JIRA.12565354.1425984357000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565354.1425984357000.38097.1442469070247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4416:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Cannot obtain DOMImplementationRegistry instance
> ------------------------------------------------
>
>                 Key: WFLY-4416
>                 URL: https://issues.jboss.org/browse/WFLY-4416
>             Project: WildFly
>          Issue Type: Bug
>          Components: XML Frameworks
>    Affects Versions: 8.2.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Jason Greene
>             Fix For: 10.0.0.CR2
>
>
> {code}
> testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase)  Time elapsed: 0.09 sec  <<< ERROR!
> java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> 	at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182)
> 	at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4404) View does not inherit
 'default' methods from interfaces( JDK8 )
In-Reply-To: <JIRA.12564873.1425545957000@Atlassian.JIRA>
References: <JIRA.12564873.1425545957000@Atlassian.JIRA>
	<JIRA.12564873.1425545957000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564873.1425545957000.38102.1442469070360@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4404:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> View does not inherit 'default' methods from interfaces( JDK8 )
> ---------------------------------------------------------------
>
>                 Key: WFLY-4404
>                 URL: https://issues.jboss.org/browse/WFLY-4404
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 10.0.0.CR2
>
>
> View and View service do not inherit JDK8 'default' methods from interfaces.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4304) Servlet authentication kicked
 off when *not* a part of any security-constraint
In-Reply-To: <JIRA.12562245.1422906276000@Atlassian.JIRA>
References: <JIRA.12562245.1422906276000@Atlassian.JIRA>
	<JIRA.12562245.1422906276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562245.1422906276000.38107.1442469070448@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4304:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-4304
>                 URL: https://issues.jboss.org/browse/WFLY-4304
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.2.0.Final
>            Reporter: Brett Meyer
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth.  If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header.  In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case.  However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped.  I'm not currently able to figure out exactly where that's occurring...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4265) Add support for caching
	handler
In-Reply-To: <JIRA.12561188.1421681349000@Atlassian.JIRA>
References: <JIRA.12561188.1421681349000@Atlassian.JIRA>
	<JIRA.12561188.1421681349000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561188.1421681349000.38114.1442469070590@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4265:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add support for caching handler
> -------------------------------
>
>                 Key: WFLY-4265
>                 URL: https://issues.jboss.org/browse/WFLY-4265
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR2
>
>
> Currently we cannot configure CacheHandler as it requires DirectCache as parameter in constructor.
> One option to fix this is to have few cache handler impls that would only have primitive parameters in constructor or  getters / setters that would configure direct cache.
> Or add proper type cache configuration to undertow subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4186) Improve Infinispan module
 compatibility with older releases
In-Reply-To: <JIRA.12559699.1418744634000@Atlassian.JIRA>
References: <JIRA.12559699.1418744634000@Atlassian.JIRA>
	<JIRA.12559699.1418744634000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559699.1418744634000.38118.1442469070660@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4186:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Improve Infinispan module compatibility with older releases
> -----------------------------------------------------------
>
>                 Key: WFLY-4186
>                 URL: https://issues.jboss.org/browse/WFLY-4186
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR2
>
>
> Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module (which, itself, was introduced in Infinispan 6), which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
> I suggest we either:
> 1. Export org.infinispan.commons from the org.infinispan module
> 2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3921) Support direct JMX mbeans as
	dependecies
In-Reply-To: <JIRA.12553872.1412175689000@Atlassian.JIRA>
References: <JIRA.12553872.1412175689000@Atlassian.JIRA>
	<JIRA.12553872.1412175689000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553872.1412175689000.38122.1442469070751@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3921:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Support direct JMX mbeans as dependecies
> ----------------------------------------
>
>                 Key: WFLY-3921
>                 URL: https://issues.jboss.org/browse/WFLY-3921
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMX
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: 10.0.0.CR2
>
>
> We should be able to depend on existing mbeans from jboss-service.xml.
> (e.g. mbeans registered directly from JMX API)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3909) Upgrade PicketBox
In-Reply-To: <JIRA.12553527.1411944613000@Atlassian.JIRA>
References: <JIRA.12553527.1411944613000@Atlassian.JIRA>
	<JIRA.12553527.1411944613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553527.1411944613000.38127.1442469070892@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3909:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Upgrade PicketBox
> -----------------
>
>                 Key: WFLY-3909
>                 URL: https://issues.jboss.org/browse/WFLY-3909
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Peter Skopek
>             Fix For: 10.0.0.CR2
>
>
> Upgrade PicketBox to a version which resolves SECURITY-861.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3860) Improve dependency handling
 in clustering/infinispan subsystem tests
In-Reply-To: <JIRA.12552335.1410879436000@Atlassian.JIRA>
References: <JIRA.12552335.1410879436000@Atlassian.JIRA>
	<JIRA.12552335.1410879436000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552335.1410879436000.38132.1442469070989@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3860:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Improve dependency handling in clustering/infinispan subsystem tests
> --------------------------------------------------------------------
>
>                 Key: WFLY-3860
>                 URL: https://issues.jboss.org/browse/WFLY-3860
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 10.0.0.CR2
>
>
> The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started.
> This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions.
> Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail.
> I plan to:
> 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model.
> 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that:
> a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.)
> b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy.
> The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3853) Cache PersistenceProviders
 within the same deployment
In-Reply-To: <JIRA.12552031.1410554803000@Atlassian.JIRA>
References: <JIRA.12552031.1410554803000@Atlassian.JIRA>
	<JIRA.12552031.1410554803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552031.1410554803000.38136.1442469071063@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3853:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Cache PersistenceProviders within the same deployment
> -----------------------------------------------------
>
>                 Key: WFLY-3853
>                 URL: https://issues.jboss.org/browse/WFLY-3853
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR2
>
>
> See wildfly-dev ml discussion [http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html] about calls to PersistenceProviderResolver.getPersistenceProviders() should return a cached list.  The cache should be per deployment.  
> We can probably reuse our PersistenceProviderResolverImpl.persistenceProviderPerClassLoader map, just need to be careful that addDeploymentSpecificPersistenceProvider() is called early before any calls to getPersistenceProviders().



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3827) Update Subsystem for
	PicketLink Console
In-Reply-To: <JIRA.12551355.1410181392000@Atlassian.JIRA>
References: <JIRA.12551355.1410181392000@Atlassian.JIRA>
	<JIRA.12551355.1410181392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551355.1410181392000.38139.1442469071120@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3827:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Update Subsystem for PicketLink Console
> ---------------------------------------
>
>                 Key: WFLY-3827
>                 URL: https://issues.jboss.org/browse/WFLY-3827
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3816) ClassNotFoundException
 com.ibm.crypto.provider.IBMJCE with IBM JDK
In-Reply-To: <JIRA.12551200.1409906653000@Atlassian.JIRA>
References: <JIRA.12551200.1409906653000@Atlassian.JIRA>
	<JIRA.12551200.1409906653000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551200.1409906653000.38144.1442469071224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3816:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> ClassNotFoundException com.ibm.crypto.provider.IBMJCE with IBM JDK
> ------------------------------------------------------------------
>
>                 Key: WFLY-3816
>                 URL: https://issues.jboss.org/browse/WFLY-3816
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.1.0.Final
>         Environment: Linux / Aix ; IBM JDK 1.6
>            Reporter: Yannick Lorenzati
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> I use Jboss AS 7.2.0 with IBM JDK 1.6
> One of my applications try to load the security provider com.ibm.crypto.provider.IBMJCE but I got an ClassNotFoundException.
> I think it?s because in the ibm.jdk module.xml we need to add the package of the security provider like this
> <module xmlns="urn:jboss:module:1.1" name="ibm.jdk">
>     <resources>
>     </resources>
>     <dependencies>
>         <system export="true">
>             <paths>
>                 <path name="com/ibm"/>
>                 <path name="com/ibm/jvm"/>
>                 <path name="com/ibm/jvm/io"/>
>                 <path name="com/ibm/jvm/util"/>
>                 <path name="com/ibm/match"/>
>                 <path name="com/ibm/misc"/>
>                 <path name="com/ibm/net"/>
>                 <path name="com/ibm/nio"/>
>                 <path name="com/ibm/nio/ch"/>
>                 <path name="com/ibm/security/auth"/>
>                 <path name="com/ibm/security/bootstrap"/>
>                 <path name="com/ibm/security/auth/module"/>
>                 <path name="com/ibm/security/util"/>
>             </paths>
>         </system>
>     </dependencies>
> </module> 
> We need to add this 
>     	<path name="com/ibm/crypto"/>
>          <path name="com/ibm/crypto/provider"/>
> Can't do a pull request at work, but i hope this help



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 17 01:51:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3681) General Schema Sync with EAP
In-Reply-To: <JIRA.12547683.1406573811000@Atlassian.JIRA>
References: <JIRA.12547683.1406573811000@Atlassian.JIRA>
	<JIRA.12547683.1406573811000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547683.1406573811000.38152.1442469071441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3681:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> General Schema Sync with EAP
> ----------------------------
>
>                 Key: WFLY-3681
>                 URL: https://issues.jboss.org/browse/WFLY-3681
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> This may actually be more about pushing some changes to EAP, new schemas are being tracked by individual issues but for the remaining schemas where cosmetic changes have been made or corrections to default values and min/max occurs we need to sync with EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3805)
 JGroupsBroadcastGroupConfiguration Serialization Problem
In-Reply-To: <JIRA.12550991.1409749047000@Atlassian.JIRA>
References: <JIRA.12550991.1409749047000@Atlassian.JIRA>
	<JIRA.12550991.1409749047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550991.1409749047000.38149.1442469071357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3805:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> JGroupsBroadcastGroupConfiguration Serialization Problem
> --------------------------------------------------------
>
>                 Key: WFLY-3805
>                 URL: https://issues.jboss.org/browse/WFLY-3805
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.1.0.Final
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 10.0.0.CR2
>
>
> When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3639) default-web-module doesn't
 work for non default host
In-Reply-To: <JIRA.12546798.1405638566000@Atlassian.JIRA>
References: <JIRA.12546798.1405638566000@Atlassian.JIRA>
	<JIRA.12546798.1405638566000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546798.1405638566000.38161.1442469071685@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3639:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> default-web-module doesn't work for non default host
> ----------------------------------------------------
>
>                 Key: WFLY-3639
>                 URL: https://issues.jboss.org/browse/WFLY-3639
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR2
>
>
> If you use config like this:
> {code:xml}
> <host name="default-host" default-web-module="myapp1.war" alias="webapp.domain1.com"/>
>     <host name="other-host" default-web-module="myapp2.war" alias="test.domain2.net"/>
> {code}
> and have apps myapp1.war & myapp2.war deployed myappwar2.war won't be bind to other-host.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3612) Implement missing
 transformers for new bean validation subsystem
In-Reply-To: <JIRA.12546142.1405043868000@Atlassian.JIRA>
References: <JIRA.12546142.1405043868000@Atlassian.JIRA>
	<JIRA.12546142.1405043868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546142.1405043868000.38165.1442469071836@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3612:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Implement missing transformers for new bean validation subsystem
> ----------------------------------------------------------------
>
>                 Key: WFLY-3612
>                 URL: https://issues.jboss.org/browse/WFLY-3612
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, EE
>            Reporter: Brian Stansberry
>            Assignee: Eduardo Martins
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFLY-3563 is done.
> From my comment on the PR for the WFLY-3551 work:
> There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.
> If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But
> 1) it's a corner case
> 2) it may not matter anyway in terms of behavior of an app
> 3) the transformer logic we have doesn't allow us to do anything about it anyway.
> Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:12 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3608) Expose configuring allowed
	file extensions
In-Reply-To: <JIRA.12546105.1405016043000@Atlassian.JIRA>
References: <JIRA.12546105.1405016043000@Atlassian.JIRA>
	<JIRA.12546105.1405016043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546105.1405016043000.38174.1442469072669@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3608:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Expose configuring allowed file extensions
> ------------------------------------------
>
>                 Key: WFLY-3608
>                 URL: https://issues.jboss.org/browse/WFLY-3608
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>         Environment: CentOs 5.5 & Ubuntu 10.04/12.04, Wildfly 8.1.0 Final, java version 1.7.0_60
>            Reporter: Thomas Brenna
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR2
>
>
> It should be possible to modify allowed extensions without adding web.xml entry as we have it now.
> It should be an configuration option of servlet-container element. in undertow subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:12 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3583) Convert mod_cluster excluded
 context into an xs:list of host:context
In-Reply-To: <JIRA.12545575.1404411193000@Atlassian.JIRA>
References: <JIRA.12545575.1404411193000@Atlassian.JIRA>
	<JIRA.12545575.1404411193000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545575.1404411193000.38177.1442469072723@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3583:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Convert mod_cluster excluded context into an xs:list of host:context
> --------------------------------------------------------------------
>
>                 Key: WFLY-3583
>                 URL: https://issues.jboss.org/browse/WFLY-3583
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR2
>
>
> {noformat}
>     // TODO: Convert into an xs:list of host:context
>     static final SimpleAttributeDefinition EXCLUDED_CONTEXTS = SimpleAttributeDefinitionBuilder.create(CommonAttributes.EXCLUDED_CONTEXTS, ModelType.STRING, true)
>             .setAllowExpression(true)
>             .setDefaultValue(new ModelNode("ROOT,invoker,jbossws,juddi,console"))
>             .setRestartAllServices()
>             .build();
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:12 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:12 -0400 (EDT)
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.38180.1442469072791@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3582:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> 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
>             Fix For: 10.0.0.CR2
>
>
> As per https://github.com/wildfly/wildfly/pull/6449



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:12 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3573) Adding incorrect JGroups
 protocol should provide better error description than CNFE
In-Reply-To: <JIRA.12545317.1404299531000@Atlassian.JIRA>
References: <JIRA.12545317.1404299531000@Atlassian.JIRA>
	<JIRA.12545317.1404299531000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545317.1404299531000.38185.1442469072940@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3573:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Adding incorrect JGroups protocol should provide better error description than CNFE
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-3573
>                 URL: https://issues.jboss.org/browse/WFLY-3573
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>              Labels: ux
>             Fix For: 10.0.0.CR2
>
>
> As reported by the community user:
> {noformat}
> [standalone at localhost:9990 / #] list-batch
> #1 /subsystem=jgroups/stack=test:add()
> #2 /subsystem=jgroups/stack=test/transport=TRANSPORT:add(type="udp",socket-binding=jgroups-udp)
> #3 /subsystem=jgroups/stack=test:add-protocol(type=FD_SOCK,socket-binding=jgroups-udp-fd)
> [standalone at localhost:9990 / #] run-batch 
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0158: Operation handler failed: java.lang.ClassNotFoundException: org.jgroups.protocols.udp from [Module \"org.jboss.as.clustering.jgroups:main\" from local module loader @4d9f6ce5 (finder: local module finder @1da65633 (roots: /home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules,/home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]"}}
> [standalone at localhost:9990 / #] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3555) Find better place / fix
 @ignored tests in core suite
In-Reply-To: <JIRA.12545051.1403904664000@Atlassian.JIRA>
References: <JIRA.12545051.1403904664000@Atlassian.JIRA>
	<JIRA.12545051.1403904664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545051.1403904664000.38188.1442469073031@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3555:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Find better place / fix @ignored tests in core suite
> ----------------------------------------------------
>
>                 Key: WFLY-3555
>                 URL: https://issues.jboss.org/browse/WFLY-3555
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR2
>
>
> tests that need revisiting and cleanup / moving stuff around:
> org.wildfly.core.test.standalone.mgmt.api.ValidateOperationOperationTestCase
> org.jboss.as.test.integration.management.http.HttpPostMgmtOpsTestCase#testAddRemoveOperation



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still
 fails intermittently
In-Reply-To: <JIRA.12544517.1403276265000@Atlassian.JIRA>
References: <JIRA.12544517.1403276265000@Atlassian.JIRA>
	<JIRA.12544517.1403276265000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544517.1403276265000.38193.1442469073125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3532:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


>  RemoteFailoverTestCase still fails intermittently
> --------------------------------------------------
>
>                 Key: WFLY-3532
>                 URL: https://issues.jboss.org/browse/WFLY-3532
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.CR2
>
>
> Fail rate is at 1.5% atm.
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=3213279503671281753&tab=testDetails
> (making affected version alpha, but indeed its master)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3491) All key and trust stores
 should be reloadable.
In-Reply-To: <JIRA.12543729.1402657919000@Atlassian.JIRA>
References: <JIRA.12543729.1402657919000@Atlassian.JIRA>
	<JIRA.12543729.1402657919000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543729.1402657919000.38196.1442469073179@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3491:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> All key and trust stores should be reloadable.
> ----------------------------------------------
>
>                 Key: WFLY-3491
>                 URL: https://issues.jboss.org/browse/WFLY-3491
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> Some stores may need to be self re-loading e.g. detect filesystem changes - others could be on demand via a management op.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
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.38213.1442469073481@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3290:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> 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.CR2
>
>         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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3463)
 org.apache.cxf.wsdl11.WSDLManagerImpl needs read access to the jre
 wsdl.properties
In-Reply-To: <JIRA.12543100.1402074279000@Atlassian.JIRA>
References: <JIRA.12543100.1402074279000@Atlassian.JIRA>
	<JIRA.12543100.1402074279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543100.1402074279000.38201.1442469073271@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3463:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> org.apache.cxf.wsdl11.WSDLManagerImpl needs read access to the jre wsdl.properties
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-3463
>                 URL: https://issues.jboss.org/browse/WFLY-3463
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security Manager
>    Affects Versions: 9.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.CR2
>
>
> During TCK testing (with security-manager enabled), I am seeing a java.security.AccessControlException: WFSM000001: Permission check failed for ("java.io.FilePermission" "/qa/tools/opt/x86_64/jdk1.7.0_60/jre/lib/wsdl.properties" "read")
> from org.apache.cxf.wsdl11.WSDLManagerImpl.
> Some related comments from irc:
> {quote}
> http://sourceforge.net/p/wsdl4j/patches/1/
> <asoldano> smarlow, I'm currently working around the problem (when running with security manager on) by setting "-Djavax.wsdl.factory.WSDLFactory=com.ibm.wsdl.factory.WSDLFactoryImpl" when starting the jvm
> {quote}
> Seems related to [https://issues.apache.org/jira/browse/TUSCANY-3925] which also has a patch.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
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.38205.1442469073360@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3434:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> 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
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3224) SSL The Last Round
In-Reply-To: <JIRA.12537340.1396722411000@Atlassian.JIRA>
References: <JIRA.12537340.1396722411000@Atlassian.JIRA>
	<JIRA.12537340.1396722411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12537340.1396722411000.38218.1442469073562@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3224:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> SSL The Last Round
> ------------------
>
>                 Key: WFLY-3224
>                 URL: https://issues.jboss.org/browse/WFLY-3224
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> I could probably list most components in the components box, anyway this is a top level task to contain all of the SSL enhancements required so that they can be addressed once and for all.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3064) Remove
 org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase
 test case.
In-Reply-To: <JIRA.12534003.1393958385000@Atlassian.JIRA>
References: <JIRA.12534003.1393958385000@Atlassian.JIRA>
	<JIRA.12534003.1393958385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534003.1393958385000.38221.1442469073630@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3064:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case.
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3064
>                 URL: https://issues.jboss.org/browse/WFLY-3064
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> A new test case was added under WFLY-3063 that demonstrates the correct way to do this so now remove the original way that depended on internal APIs.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2955) Audit logging should also be
 able to use PKCS#11 for keystores.
In-Reply-To: <JIRA.12532489.1392726585000@Atlassian.JIRA>
References: <JIRA.12532489.1392726585000@Atlassian.JIRA>
	<JIRA.12532489.1392726585000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532489.1392726585000.38227.1442469073882@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2955:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Audit logging should also be able to use PKCS#11 for keystores.
> ---------------------------------------------------------------
>
>                 Key: WFLY-2955
>                 URL: https://issues.jboss.org/browse/WFLY-2955
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2982) refactor two phase
 persistence unit services (PhaseOnePersistenceUnitServiceImpl +
 PersistenceUnitServiceImpl) into one service
In-Reply-To: <JIRA.12532872.1392925405000@Atlassian.JIRA>
References: <JIRA.12532872.1392925405000@Atlassian.JIRA>
	<JIRA.12532872.1392925405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532872.1392925405000.38224.1442469073793@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2982:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2982
>                 URL: https://issues.jboss.org/browse/WFLY-2982
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR2
>
>
> Related feedback from https://github.com/wildfly/wildfly/pull/4722:
> {quote}
> This is asymetrical, so if this service , and phase one are stopped, and then phase 1 is started again, phase 2 will appear started. The side effects seem minor though
> {quote}
> {quote}
> We have a long term goal to somehow verify every service can be stopped and started with the expected effect. Right now many of our services are not restartable which makes potential new features like partial deployment standby hard to achieve. So Im just offering pointers whenever I see lifecycle symmetry issues.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2953) Add support to specify
 security provider for key and trust stores used by HornetQ
In-Reply-To: <JIRA.12532480.1392722055000@Atlassian.JIRA>
References: <JIRA.12532480.1392722055000@Atlassian.JIRA>
	<JIRA.12532480.1392722055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532480.1392722055000.38230.1442469073989@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2953:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add support to specify security provider for key and trust stores used by HornetQ
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2953
>                 URL: https://issues.jboss.org/browse/WFLY-2953
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2876) Add mod_cluster support for
 all Undertow servers, not only the default-server
In-Reply-To: <JIRA.12531396.1391704235000@Atlassian.JIRA>
References: <JIRA.12531396.1391704235000@Atlassian.JIRA>
	<JIRA.12531396.1391704235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531396.1391704235000.38235.1442469074081@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2876:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add mod_cluster support for all Undertow servers, not only the default-server
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2876
>                 URL: https://issues.jboss.org/browse/WFLY-2876
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR2
>
>
> Currently only the default host is registered with the proxy.
> This will require:
> * configuration change for listener<>host mapping
> * instance-id be configured per server, instead of per whole undertow subsystem (or just appended to the unique server name)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2858) JPA doesn't parse for
 "urn:jboss:jpa" namespace in jboss-all.xml
In-Reply-To: <JIRA.12531038.1391444897000@Atlassian.JIRA>
References: <JIRA.12531038.1391444897000@Atlassian.JIRA>
	<JIRA.12531038.1391444897000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531038.1391444897000.38239.1442469074198@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2858:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> JPA doesn't parse for "urn:jboss:jpa" namespace in jboss-all.xml
> ----------------------------------------------------------------
>
>                 Key: WFLY-2858
>                 URL: https://issues.jboss.org/browse/WFLY-2858
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> Looks like the parser is only parsing for "http://www.jboss.com/xml/ns/javaee" and never for "urn:jboss:jpa". This makes the schema less useful.
> https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/docs/schema/jboss-jpa_1_0.xsd
> Example file:
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/epcpropagation/shallow/jboss-all.xml



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2845) On WildFly clean shutdown:
 failed marshalling rsp (UnsuccessfulResponse)
In-Reply-To: <JIRA.12530755.1391092956000@Atlassian.JIRA>
References: <JIRA.12530755.1391092956000@Atlassian.JIRA>
	<JIRA.12530755.1391092956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530755.1391092956000.38244.1442469074354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2845:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2845
>                 URL: https://issues.jboss.org/browse/WFLY-2845
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: RHEL6 x86_64; Oracle JDK 7
>            Reporter: Michal Karm Babacek
>            Assignee: Paul Ferraro
>              Labels: clustering
>             Fix For: 10.0.0.CR2
>
>
> I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}}  [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:
> {noformat}
> 08:59:33,341 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
> 08:59:33,368 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
> 08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,392 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms
> {noformat}
> In the log.  It's a non-deterministic problem and it does not emerge always.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2652) Add/remove load metric
 operations should not require service restart
In-Reply-To: <JIRA.12527929.1386945153000@Atlassian.JIRA>
References: <JIRA.12527929.1386945153000@Atlassian.JIRA>
	<JIRA.12527929.1386945153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527929.1386945153000.38248.1442469074430@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2652:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add/remove load metric operations should not require service restart
> --------------------------------------------------------------------
>
>                 Key: WFLY-2652
>                 URL: https://issues.jboss.org/browse/WFLY-2652
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2567) Custom authentication
 mechanism definition - Subsystem Level
In-Reply-To: <JIRA.12526043.1385388220000@Atlassian.JIRA>
References: <JIRA.12526043.1385388220000@Atlassian.JIRA>
	<JIRA.12526043.1385388220000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526043.1385388220000.38252.1442469074549@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2567:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Custom authentication mechanism definition - Subsystem Level
> ------------------------------------------------------------
>
>                 Key: WFLY-2567
>                 URL: https://issues.jboss.org/browse/WFLY-2567
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2552) Undertow
 AuthenticationMechanism Configuration Overrides
In-Reply-To: <JIRA.12525944.1385146370000@Atlassian.JIRA>
References: <JIRA.12525944.1385146370000@Atlassian.JIRA>
	<JIRA.12525944.1385146370000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525944.1385146370000.38261.1442469074723@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2552:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Undertow AuthenticationMechanism Configuration Overrides
> --------------------------------------------------------
>
>                 Key: WFLY-2552
>                 URL: https://issues.jboss.org/browse/WFLY-2552
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR2
>
>
> General article covering the security configuration for Undertow / WildFly: -
> https://community.jboss.org/wiki/UndertowSecurityConfiguration



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2492) <valid-connection-checker>
 does not have module attribute
In-Reply-To: <JIRA.12524847.1384237418000@Atlassian.JIRA>
References: <JIRA.12524847.1384237418000@Atlassian.JIRA>
	<JIRA.12524847.1384237418000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524847.1384237418000.38269.1442469074935@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2492:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> <valid-connection-checker> does not have module attribute
> ---------------------------------------------------------
>
>                 Key: WFLY-2492
>                 URL: https://issues.jboss.org/browse/WFLY-2492
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: James Livingston
>            Assignee: Lin Gao
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> A datasource's <valid-connection-checker> element lets you specify the class name. It does not let you specify the module name, so you can only use IJ-provided ones.  It should let you specify a module name too, so you can use custom connection checkers.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2440) Thread pool
 AccessControlContext Propagation
In-Reply-To: <JIRA.12518017.1383655122000@Atlassian.JIRA>
References: <JIRA.12518017.1383655122000@Atlassian.JIRA>
	<JIRA.12518017.1383655122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518017.1383655122000.38278.1442469075171@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2440:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Thread pool AccessControlContext Propagation
> --------------------------------------------
>
>                 Key: WFLY-2440
>                 URL: https://issues.jboss.org/browse/WFLY-2440
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> A decision was made within Java that newly created threads should inherit the access control context of their creator.  
> In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have.
> Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread.
> This may affect components outside of WildFly but I am raising it here as a top level task.
> Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2448) Print IOR to a user specified
	file
In-Reply-To: <JIRA.12518153.1383748388000@Atlassian.JIRA>
References: <JIRA.12518153.1383748388000@Atlassian.JIRA>
	<JIRA.12518153.1383748388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518153.1383748388000.38274.1442469075100@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2448:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Print IOR to a user specified file
> ----------------------------------
>
>                 Key: WFLY-2448
>                 URL: https://issues.jboss.org/browse/WFLY-2448
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows, Solaris, Linux
>            Reporter: Sumanth M S
>            Assignee: Stefan Guilhen
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>         Attachments: WFLY-2448.patch
>
>
> Jboss AS prints Corba IOR on console or log file. Many applications look for a file at a predefined location from where it can read the IOR; as it is difficult to read IOR programatically from a log file or console.
> An environment variable can be defined in standalone.conf to let the user specify the file location to which JBoss will print the IOR along with printing on the console.
> The solution has been tried and seems working. Please let us know if the solution can be submitted.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2426) Easily accessible static
 information describing the release
In-Reply-To: <JIRA.12509239.1383250273000@Atlassian.JIRA>
References: <JIRA.12509239.1383250273000@Atlassian.JIRA>
	<JIRA.12509239.1383250273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509239.1383250273000.38286.1442469075357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2426:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Easily accessible static information describing the release
> -----------------------------------------------------------
>
>                 Key: WFLY-2426
>                 URL: https://issues.jboss.org/browse/WFLY-2426
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Ondrej Zizka
>              Labels: build, integration, jbds, layers, version
>             Fix For: 10.0.0.CR2
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization for



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@Atlassian.JIRA>
References: <JIRA.12509159.1383210125000@Atlassian.JIRA>
	<JIRA.12509159.1383210125000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.38301.1442469075881@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2422:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFLY-2422
>                 URL: https://issues.jboss.org/browse/WFLY-2422
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:16 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350000@Atlassian.JIRA>
References: <JIRA.12508815.1382711350000@Atlassian.JIRA>
	<JIRA.12508815.1382711350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350000.38330.1442469076541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2387:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.CR2
>
>         Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	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) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:16 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2297) Log reasons for implicit
	dependencies
In-Reply-To: <JIRA.12502954.1381757546000@Atlassian.JIRA>
References: <JIRA.12502954.1381757546000@Atlassian.JIRA>
	<JIRA.12502954.1381757546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502954.1381757546000.38334.1442469076766@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2297:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Log reasons for implicit dependencies
> -------------------------------------
>
>                 Key: WFLY-2297
>                 URL: https://issues.jboss.org/browse/WFLY-2297
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> We should log a {{DEBUG}} or {{TRACE}} message whenever we add an implicit dependency to a module, documenting the reason for the addition (e.g. adding because it's a servlet deployment, or because a particular annotation was used, etc.)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:16 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2102) Improve deployment annotation
 parsing error message
In-Reply-To: <JIRA.12500878.1379471722000@Atlassian.JIRA>
References: <JIRA.12500878.1379471722000@Atlassian.JIRA>
	<JIRA.12500878.1379471722000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500878.1379471722000.38339.1442469076847@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2102:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


>  Improve deployment annotation parsing error message 
> -----------------------------------------------------
>
>                 Key: WFLY-2102
>                 URL: https://issues.jboss.org/browse/WFLY-2102
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: 10.0.0.CR2
>
>
> Improve deployment annotation parsing error message 
> Code such as this below, will error with IllegalArgumentException: Empty name segment is not allowed for env.  The env is not enough information to identify what the issue is.
> @Singleton
> @Startup
> public class TestEJB {
>   @Resource(name="/queue/test")
>   private Queue queue;
> }
> Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed for env
> 	at org.jboss.msc.service.ServiceName.of(ServiceName.java:85) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> 	at org.jboss.msc.service.ServiceName.append(ServiceName.java:112) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> 	at org.jboss.as.naming.deployment.ContextNames.buildServiceName(ContextNames.java:183)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:195)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:186)
> 	at org.jboss.as.naming.deployment.ContextNames.bindInfoFor(ContextNames.java:141)
> 	at org.jboss.as.ee.component.OptionalLookupInjectionSource.getResourceValue(OptionalLookupInjectionSource.java:84)
> 	at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:1019)
> 	at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:998)
> 	at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:138)
> 	at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95)
> 	... 6 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1882) JCA should be able to access
 the CDI-enabled ValidatorFactory
In-Reply-To: <JIRA.12498614.1376506818000@Atlassian.JIRA>
References: <JIRA.12498614.1376506818000@Atlassian.JIRA>
	<JIRA.12498614.1376506818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498614.1376506818000.38350.1442469077042@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1882:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> JCA should be able to access the CDI-enabled ValidatorFactory
> -------------------------------------------------------------
>
>                 Key: WFLY-1882
>                 URL: https://issues.jboss.org/browse/WFLY-1882
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Farah Juma
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR2
>
>
> The JCAValidatorFactory is currently a copy of an older version of the EE LazyValidatorFactory. The delegate of the EE LazyValidatorFactory was recently replaced with a CDI-enabled ValidatorFactory (see WFLY-529). JCA needs to be able to access the CDI-enabled ValidatorFactory as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:16 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:16 -0400 (EDT)
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.38345.1442469076953@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2100:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> 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
>             Fix For: 10.0.0.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1832) Wildfly High Availability
 Guide: Migration and Changes From Previous Versions write up
In-Reply-To: <JIRA.12497993.1375720397000@Atlassian.JIRA>
References: <JIRA.12497993.1375720397000@Atlassian.JIRA>
	<JIRA.12497993.1375720397000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497993.1375720397000.38362.1442469077318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1832:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Wildfly High Availability Guide: Migration and Changes From Previous Versions write up 
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-1832
>                 URL: https://issues.jboss.org/browse/WFLY-1832
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR2
>
>
> https://docs.jboss.org/author/display/WFLY8/Changes+From+Previous+Versions



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1878) Make concurrency items in ee
 subsystem use KeepAliveTimeAttributeDefinition
In-Reply-To: <JIRA.12498581.1376490516000@Atlassian.JIRA>
References: <JIRA.12498581.1376490516000@Atlassian.JIRA>
	<JIRA.12498581.1376490516000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498581.1376490516000.38354.1442469077147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1878:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Make concurrency items in ee subsystem use KeepAliveTimeAttributeDefinition
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1878
>                 URL: https://issues.jboss.org/browse/WFLY-1878
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, EE
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.0.CR2
>
>
> Have the time-period attributes in ee use KeepAliveAD (or a renamed, slightly more generic version thereof.)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1877) Make
 KeepAliveTimeAttributeDefinition deal with both a simple long and a complex
 attribute
In-Reply-To: <JIRA.12498579.1376490426000@Atlassian.JIRA>
References: <JIRA.12498579.1376490426000@Atlassian.JIRA>
	<JIRA.12498579.1376490426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498579.1376490426000.38358.1442469077218@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1877:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Make KeepAliveTimeAttributeDefinition deal with both a simple long and a complex attribute
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1877
>                 URL: https://issues.jboss.org/browse/WFLY-1877
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.0.CR2
>
>
> This attribute should support either a simple value or a complex one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1831) Wildfly High Availability
 Guide: Clustering Monitor subsystem write up
In-Reply-To: <JIRA.12497992.1375720334000@Atlassian.JIRA>
References: <JIRA.12497992.1375720334000@Atlassian.JIRA>
	<JIRA.12497992.1375720334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497992.1375720334000.38366.1442469077425@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1831:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Wildfly High Availability Guide: Clustering Monitor subsystem write up
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1831
>                 URL: https://issues.jboss.org/browse/WFLY-1831
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.CR2
>
>
> https://docs.jboss.org/author/display/WFLY8/Clustering+Monitor+Subsystem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1829) Wildfly High Availability
 Guide: EJB Services/Subsystem write up
In-Reply-To: <JIRA.12497990.1375720208000@Atlassian.JIRA>
References: <JIRA.12497990.1375720208000@Atlassian.JIRA>
	<JIRA.12497990.1375720208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497990.1375720208000.38369.1442469077481@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1829:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Wildfly High Availability Guide: EJB Services/Subsystem write up
> ----------------------------------------------------------------
>
>                 Key: WFLY-1829
>                 URL: https://issues.jboss.org/browse/WFLY-1829
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>             Fix For: 10.0.0.CR2
>
>
> https://docs.jboss.org/author/display/WFLY8/EJB+Subsystem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1725) Update The Wildfly High
	Availability Guide
In-Reply-To: <JIRA.12496926.1374260551000@Atlassian.JIRA>
References: <JIRA.12496926.1374260551000@Atlassian.JIRA>
	<JIRA.12496926.1374260551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496926.1374260551000.38383.1442469077767@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1725:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Update The Wildfly High Availability Guide 
> -------------------------------------------
>
>                 Key: WFLY-1725
>                 URL: https://issues.jboss.org/browse/WFLY-1725
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.CR2
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
> https://docs.jboss.org/author/display/WFLY8/High+Availability+Guide



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1827) Wildfly High Availability
 Guide: Clustered Single Sign-on (SSO) write up
In-Reply-To: <JIRA.12497988.1375720092000@Atlassian.JIRA>
References: <JIRA.12497988.1375720092000@Atlassian.JIRA>
	<JIRA.12497988.1375720092000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497988.1375720092000.38373.1442469077550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1827:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Wildfly High Availability Guide: Clustered Single Sign-on (SSO) write up
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1827
>                 URL: https://issues.jboss.org/browse/WFLY-1827
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR2
>
>
> https://docs.jboss.org/author/display/WFLY8/Clustered+SSO



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1825) Wildfly High Availability
 Guide: Infinispan write up
In-Reply-To: <JIRA.12497986.1375719976000@Atlassian.JIRA>
References: <JIRA.12497986.1375719976000@Atlassian.JIRA>
	<JIRA.12497986.1375719976000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497986.1375719976000.38377.1442469077661@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1825:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Wildfly High Availability Guide: Infinispan write up
> ----------------------------------------------------
>
>                 Key: WFLY-1825
>                 URL: https://issues.jboss.org/browse/WFLY-1825
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.CR2
>
>
> https://docs.jboss.org/author/display/WFLY8/Infinispan+Subsystem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:18 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1535) SSLEJBRemoteClientTestCase
 runs into intermittent failures
In-Reply-To: <JIRA.12494315.1371223824000@Atlassian.JIRA>
References: <JIRA.12494315.1371223824000@Atlassian.JIRA>
	<JIRA.12494315.1371223824000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494315.1371223824000.38397.1442469078054@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1535:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> SSLEJBRemoteClientTestCase runs into intermittent failures
> ----------------------------------------------------------
>
>                 Key: WFLY-1535
>                 URL: https://issues.jboss.org/browse/WFLY-1535
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR2
>
>
> SSLEJBRemoteClientTestCase runs into intermittent failures on TeamCity. To make matters worse, a failure in one test method can have a side effect on other test methods in that testcase, given the way it's written. The entire run is here http://teamcity.cafe-babe.org/viewLog.html?buildId=5251&tab=buildResultsDiv&buildTypeId=bt27.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:18 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1525) Filesystem JAR permission
	processing
In-Reply-To: <JIRA.12494245.1371164451000@Atlassian.JIRA>
References: <JIRA.12494245.1371164451000@Atlassian.JIRA>
	<JIRA.12494245.1371164451000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494245.1371164451000.38400.1442469078118@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1525:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Filesystem JAR permission processing
> ------------------------------------
>
>                 Key: WFLY-1525
>                 URL: https://issues.jboss.org/browse/WFLY-1525
>             Project: WildFly
>          Issue Type: Task
>          Components: Security Manager
>            Reporter: David Lloyd
>             Fix For: 10.0.0.CR2
>
>
> Parse {{jboss-permission.xml}} files found in filesystem and (old-style) extension JARs to establish their base permission set.  If no such file is found then default to the minimal permission set.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:17 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1598) Out of the box SSL - or
	shortly after.
In-Reply-To: <JIRA.12495221.1372327189000@Atlassian.JIRA>
References: <JIRA.12495221.1372327189000@Atlassian.JIRA>
	<JIRA.12495221.1372327189000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495221.1372327189000.38392.1442469077954@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1598:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Out of the box SSL - or shortly after.
> --------------------------------------
>
>                 Key: WFLY-1598
>                 URL: https://issues.jboss.org/browse/WFLY-1598
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: management_security,, management_sso
>             Fix For: 10.0.0.CR2
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
>  - If we ship a default keystore then everyone has access to the private key.
>  - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:18 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1415) Move away from expensive enum
	switch
In-Reply-To: <JIRA.12493134.1369842373000@Atlassian.JIRA>
References: <JIRA.12493134.1369842373000@Atlassian.JIRA>
	<JIRA.12493134.1369842373000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493134.1369842373000.38405.1442469078216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1415:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Move away from expensive enum switch
> ------------------------------------
>
>                 Key: WFLY-1415
>                 URL: https://issues.jboss.org/browse/WFLY-1415
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Priority: Minor
>              Labels: janitor
>             Fix For: 10.0.0.CR2
>
>
> We use enums and enum switch extensively.  These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead.  The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes.  The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:18 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-569) Implement an account lockout
 mechanism for domain management.
In-Reply-To: <JIRA.12446171.1314976732000@Atlassian.JIRA>
References: <JIRA.12446171.1314976732000@Atlassian.JIRA>
	<JIRA.12446171.1314976732000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446171.1314976732000.38419.1442469078522@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-569:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Implement an account lockout mechanism for domain management.
> -------------------------------------------------------------
>
>                 Key: WFLY-569
>                 URL: https://issues.jboss.org/browse/WFLY-569
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Common_Authentication, Realm_Management, management_security,
>             Fix For: 10.0.0.CR2
>
>
> One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: -
> - Consider an option to update the remote store if possible.
> - If not cache a backlisted user until an admin unlocks that account
> Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:18 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1136) Common mechanism for all
 secure socket definitions
In-Reply-To: <JIRA.12413600.1277840615000@Atlassian.JIRA>
References: <JIRA.12413600.1277840615000@Atlassian.JIRA>
	<JIRA.12413600.1277840615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12413600.1277840615000.38416.1442469078476@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1136:
-------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Common mechanism for all secure socket definitions
> --------------------------------------------------
>
>                 Key: WFLY-1136
>                 URL: https://issues.jboss.org/browse/WFLY-1136
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> The JAASSecurityDomain in my opinion should
> >> handle all secure socket definitions. Mod-cluster currently does
> >> not support JAASSecurityDomains.
> I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:18 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-487) Verify audit implications and
	required APIs
In-Reply-To: <JIRA.12482333.1357812301000@Atlassian.JIRA>
References: <JIRA.12482333.1357812301000@Atlassian.JIRA>
	<JIRA.12482333.1357812301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482333.1357812301000.38425.1442469078628@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-487:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Verify audit implications and required APIs
> -------------------------------------------
>
>                 Key: WFLY-487
>                 URL: https://issues.jboss.org/browse/WFLY-487
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: authentication_service
>             Fix For: 10.0.0.CR2
>
>
> Auditing may be logging as the user that executes a request, if we have used a trust relationship for a request to be run as a different user we need to be able to track back to identify how the user for the request was selected.
> i.e. If userA runs something as userB and does something bad we must be able to track back that it was userA making the overall request without userB getting the blame.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:19 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-483) Allow more control over
 authentication for server to server communication through
 remote-outbound-connection
In-Reply-To: <JIRA.12469282.1340292148000@Atlassian.JIRA>
References: <JIRA.12469282.1340292148000@Atlassian.JIRA>
	<JIRA.12469282.1340292148000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469282.1340292148000.38457.1442469079307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-483:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Allow more control over authentication for server to server communication through remote-outbound-connection
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-483
>                 URL: https://issues.jboss.org/browse/WFLY-483
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Remoting, Security
>            Reporter: jaikiran pai
>            Assignee: Darran Lofthouse
>              Labels: authentication_service
>             Fix For: 10.0.0.CR2
>
>
> Right now for server to server communication via a remote-outbound-connection, we expect a static username to be specified (along with the security realm). User applications which use this remote-outbound-connection, for example an EJB application, do not have much control over the user/pass information, since the username is static. This further acts a drawback since the username that's used to connect to the remote server will be used as the (application) user who invoked the EJB.
> It would be good to allow more control over the authentication for the remote-outbound-connection.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:19 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:19 -0400 (EDT)
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.38463.1442469079420@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-473:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> 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.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:19 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-466) Detect JBossWS Configuration
 for @PermitAll endpoints within Undertow subsystem.
In-Reply-To: <JIRA.12489705.1366199995000@Atlassian.JIRA>
References: <JIRA.12489705.1366199995000@Atlassian.JIRA>
	<JIRA.12489705.1366199995000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489705.1366199995000.38467.1442469079504@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-466:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-466
>                 URL: https://issues.jboss.org/browse/WFLY-466
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container.
> This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:19 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-463) Add utility for creating and
 destorying modules in tests
In-Reply-To: <JIRA.12488631.1365114411000@Atlassian.JIRA>
References: <JIRA.12488631.1365114411000@Atlassian.JIRA>
	<JIRA.12488631.1365114411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488631.1365114411000.38471.1442469079701@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-463:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add utility for creating and destorying modules in tests
> --------------------------------------------------------
>
>                 Key: WFLY-463
>                 URL: https://issues.jboss.org/browse/WFLY-463
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Stuart Douglas
>            Assignee: Ondrej Zizka
>             Fix For: 10.0.0.CR2
>
>
> Lots of tests create and destroy a static module to test functionaility involving static modules. If possible all this code should be moved into some kind of static module builder utility. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-447) Connection Reauthentication
 and Security Propagation
In-Reply-To: <JIRA.12478814.1352367103000@Atlassian.JIRA>
References: <JIRA.12478814.1352367103000@Atlassian.JIRA>
	<JIRA.12478814.1352367103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478814.1352367103000.38486.1442469080011@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-447:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Connection Reauthentication and Security Propagation
> ----------------------------------------------------
>
>                 Key: WFLY-447
>                 URL: https://issues.jboss.org/browse/WFLY-447
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: authentication_service
>             Fix For: 10.0.0.CR2
>
>
> This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting.  
> This is to predominantly cover two major scenarios: -
>  - Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user.
>  - Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as.
> The following document is building up the requirements and design considerations and decisions: -
> https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPropagation



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-443) Add integration test of Seam2
	integration
In-Reply-To: <JIRA.12489018.1365601723000@Atlassian.JIRA>
References: <JIRA.12489018.1365601723000@Atlassian.JIRA>
	<JIRA.12489018.1365601723000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489018.1365601723000.38491.1442469080110@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-443:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add integration test of Seam2 integration
> -----------------------------------------
>
>                 Key: WFLY-443
>                 URL: https://issues.jboss.org/browse/WFLY-443
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>         Environment: https://github.com/jbossas/jboss-as/commit/b036d103ed503b0099d3f62c1c50f954aef03137 will break the Seam 2 integration since Seam2Processor will look for the specific jar name. Yet the commit did not result in any testsuite failure. So, it seems we have no integration testing.
>            Reporter: Brian Stansberry
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-442) Review of AccessController and
 PrivilegedAction use across AS7
In-Reply-To: <JIRA.12482399.1357892166000@Atlassian.JIRA>
References: <JIRA.12482399.1357892166000@Atlassian.JIRA>
	<JIRA.12482399.1357892166000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482399.1357892166000.38498.1442469080224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-442:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Review of AccessController and PrivilegedAction use across AS7
> --------------------------------------------------------------
>
>                 Key: WFLY-442
>                 URL: https://issues.jboss.org/browse/WFLY-442
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: investigation_required
>             Fix For: 10.0.0.CR2
>
>
> The following needs reviewing across AS7: -
>  - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable).
>  - Use of AccessController even though there is no SecurityManager set.
>  - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED
>  - Utility methods with visibility too high.
>  - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction.
>  - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-441) If possible,
 eliminate the NonTxEmCloser by closing the EM immediately after
 each EM invocation
In-Reply-To: <JIRA.12455914.1325826336000@Atlassian.JIRA>
References: <JIRA.12455914.1325826336000@Atlassian.JIRA>
	<JIRA.12455914.1325826336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455914.1325826336000.38502.1442469080334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-441:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-441
>                 URL: https://issues.jboss.org/browse/WFLY-441
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> For Queries, handoff the EntityManager to a Query object wrapper and have the Query object finalizer close the EntityManager.  
> Make sure that we respect JPA 2.0 section 3.8.6 (detach objects returned from Query object).
> 1.  Methods that return a Query, will hand off the EM to the Query object wrapper.
> 2.  Other methods will close the EM at the end of the EM method invocation.
> When making this change, make sure that performance doesn't degrade.  The cost of this change, will be that each (transaction scoped non-tx) EM invocation will create a new persistence context, but we can eliminate the NonTxEmCloser which has its own overhead.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-421) Domain Mode JMX access through
 the HostController
In-Reply-To: <JIRA.12460611.1330692815000@Atlassian.JIRA>
References: <JIRA.12460611.1330692815000@Atlassian.JIRA>
	<JIRA.12460611.1330692815000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460611.1330692815000.38511.1442469080524@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-421:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Domain Mode JMX access through the HostController
> -------------------------------------------------
>
>                 Key: WFLY-421
>                 URL: https://issues.jboss.org/browse/WFLY-421
>             Project: WildFly
>          Issue Type: Task
>          Components: JMX, Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: JMX, investigation_required
>             Fix For: 10.0.0.CR2
>
>
> This task is first to review if this should be considered.
> At the moment access to JMX is provided through the remoting connector of each AS instance - this task is to consider if we should actually make it available through the host controller with the host controller acting as a proxy.
> The main motivation being to separate management and app traffic.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-431) Revisit enforcement of
 required file system permissions.
In-Reply-To: <JIRA.12486809.1362763320000@Atlassian.JIRA>
References: <JIRA.12486809.1362763320000@Atlassian.JIRA>
	<JIRA.12486809.1362763320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486809.1362763320000.38506.1442469080401@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-431:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Revisit enforcement of required file system permissions.
> --------------------------------------------------------
>
>                 Key: WFLY-431
>                 URL: https://issues.jboss.org/browse/WFLY-431
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: management_security,
>             Fix For: 10.0.0.CR2
>
>
> Now that AS8 has moved to Java 7 we can re-visit the level of control we have over file system permissions, this can be from taking more control of the local authentication mechanism to ensure incorrect permissions are not inherited to verifying sensitive configuration files are not world readable.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-414) Add a non-caching
	authentication cache
In-Reply-To: <JIRA.12455369.1324483914000@Atlassian.JIRA>
References: <JIRA.12455369.1324483914000@Atlassian.JIRA>
	<JIRA.12455369.1324483914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455369.1324483914000.38519.1442469080664@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-414:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add a non-caching authentication cache
> --------------------------------------
>
>                 Key: WFLY-414
>                 URL: https://issues.jboss.org/browse/WFLY-414
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Anil Saldhana
>             Fix For: 10.0.0.CR2
>
>
> Add an option to either disable the authentication cache or a cache implementation that does not cache.
> This is for incoming requests where we do not have a username and password available to use to retrieve an verify items from a cache.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-418) TS: Move resources to source
	packages.
In-Reply-To: <JIRA.12461401.1331565661000@Atlassian.JIRA>
References: <JIRA.12461401.1331565661000@Atlassian.JIRA>
	<JIRA.12461401.1331565661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461401.1331565661000.38514.1442469080576@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-418:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> TS: Move resources to source packages.
> --------------------------------------
>
>                 Key: WFLY-418
>                 URL: https://issues.jboss.org/browse/WFLY-418
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-399) mod_cluster subsystem: convert
 operation handlers to use OperationDefinition
In-Reply-To: <JIRA.12479868.1353944133000@Atlassian.JIRA>
References: <JIRA.12479868.1353944133000@Atlassian.JIRA>
	<JIRA.12479868.1353944133000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479868.1353944133000.38523.1442469080734@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-399:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> mod_cluster subsystem: convert operation handlers to use OperationDefinition
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-399
>                 URL: https://issues.jboss.org/browse/WFLY-399
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR2
>
>
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/LoadMetricDefinition.java:[59,59] warning: [deprecation] PropertiesAttributeDefinition(java.lang.String,java.lang.String,boolean) in org.jboss.as.controller.PropertiesAttributeDefinition has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[277,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[280,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[283,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[286,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterSubsystemAdd.java:[160,19] warning: [deprecation] setProxyList(java.lang.String) in org.jboss.modcluster.config.impl.ModClusterConfig has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterSubsystemAdd.java:[166,15] warning: [deprecation] setExcludedContexts(java.lang.String) in org.jboss.modcluster.config.impl.ModClusterConfig has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[100,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[103,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[106,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[110,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[113,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[117,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[120,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[124,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[127,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[130,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[134,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[137,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[140,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:20 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove
 WebSecurityJBossWebXmlSecurityRolesTestCase
In-Reply-To: <JIRA.12488273.1364495388000@Atlassian.JIRA>
References: <JIRA.12488273.1364495388000@Atlassian.JIRA>
	<JIRA.12488273.1364495388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488273.1364495388000.38526.1442469080786@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-383:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase
> -----------------------------------------------------------------
>
>                 Key: WFLY-383
>                 URL: https://issues.jboss.org/browse/WFLY-383
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Test Suite, Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid.
> I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-379) Fix & re-enable ignored
	security tests
In-Reply-To: <JIRA.12488028.1364302655000@Atlassian.JIRA>
References: <JIRA.12488028.1364302655000@Atlassian.JIRA>
	<JIRA.12488028.1364302655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488028.1364302655000.38533.1442469081139@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-379:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Fix & re-enable ignored security tests
> --------------------------------------
>
>                 Key: WFLY-379
>                 URL: https://issues.jboss.org/browse/WFLY-379
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>    Affects Versions: 8.0.0.Alpha1
>         Environment: AS8 with undertow
>            Reporter: Tomaz Cerar
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> AS8 with undertow fails few security tests.
> This issue is here just for tracking what they are so they can be fixed
> Still disabled tests:
> {noformat}
> SPNEGOLoginModuleTestCase
> AdvancedLdapLoginModuleTestCase
> StackingJASPITestCase
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-366) Add support for grouping to
 Infinispan subsystem
In-Reply-To: <JIRA.12456230.1326273774000@Atlassian.JIRA>
References: <JIRA.12456230.1326273774000@Atlassian.JIRA>
	<JIRA.12456230.1326273774000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456230.1326273774000.38541.1442469081335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-366:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add support for grouping to Infinispan subsystem
> ------------------------------------------------
>
>                 Key: WFLY-366
>                 URL: https://issues.jboss.org/browse/WFLY-366
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Martin Gencur
>            Assignee: Tristan Tarrant
>             Fix For: 10.0.0.CR2
>
>
> Enable setting of groups in Infinispan subsystem. More information about grouping can be found at https://docs.jboss.org/author/display/ISPN/The+Grouping+API.
> It should be possible to enable it as well as set a grouper class. The following is respective configuration for standalone Infinispan.
> {code:xml}
> <clustering>
>   <hash>
>      <groups enabled="true">
>         <grouper class="com.acme.KXGrouper" />
>      </groups>
>   </hash>
> </clustering>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-319) OpenSSL SSL certificate
 support for domain management security realms (http and native interface)
In-Reply-To: <JIRA.12463462.1333723487000@Atlassian.JIRA>
References: <JIRA.12463462.1333723487000@Atlassian.JIRA>
	<JIRA.12463462.1333723487000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463462.1333723487000.38547.1442469081468@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-319:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> OpenSSL SSL certificate support for domain management security realms (http and native interface)
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-319
>                 URL: https://issues.jboss.org/browse/WFLY-319
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security, Server
>            Reporter: Franck LEDAY
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> related to https://community.jboss.org/message/728665#728665 : 
> Request the feature to use SSL certificate issued from OpenSSL directly from SSL attribute of management interface instead of available use of JKS .



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-316) Javadoc - exclude _private.*
	packages
In-Reply-To: <JIRA.12488463.1364919092000@Atlassian.JIRA>
References: <JIRA.12488463.1364919092000@Atlassian.JIRA>
	<JIRA.12488463.1364919092000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488463.1364919092000.38551.1442469081565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-316:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Javadoc - exclude _private.* packages
> -------------------------------------
>
>                 Key: WFLY-316
>                 URL: https://issues.jboss.org/browse/WFLY-316
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Documentation
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-288) SecurityDomainJndiInjectable
 should allow "java:/jaas" prefixed security domain on demand
In-Reply-To: <JIRA.12463048.1333389594000@Atlassian.JIRA>
References: <JIRA.12463048.1333389594000@Atlassian.JIRA>
	<JIRA.12463048.1333389594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463048.1333389594000.38555.1442469081663@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-288:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-288
>                 URL: https://issues.jboss.org/browse/WFLY-288
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: 10.0.0.CR2
>
>
> Currently,  security domain strings of the form "java:/jaas/sd" are not resolving properly.  IMO we should allow users to deploy applications on AS4,5,6,7 if they need to.
> So have a flag inside the SecurityDomainJndiInjectable class that is turned off by default.  If you turn it on, then "java:/jaas" is unprefixed if present.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-277) TS: Integrate JUnitDiff
In-Reply-To: <JIRA.12460907.1331103224000@Atlassian.JIRA>
References: <JIRA.12460907.1331103224000@Atlassian.JIRA>
	<JIRA.12460907.1331103224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460907.1331103224000.38559.1442469081751@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-277:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> TS: Integrate JUnitDiff
> -----------------------
>
>                 Key: WFLY-277
>                 URL: https://issues.jboss.org/browse/WFLY-277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> Running with
> {code}
> -DjunitDiff='<path1>:<path2>:<path3>'
> {code}
> would create a comparison to given testsuite result sets (JUnit .xml and txt files).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-276) Clustering/multi-node tests
 cannot be run with -Djpda debugger
In-Reply-To: <JIRA.12453411.1322641838000@Atlassian.JIRA>
References: <JIRA.12453411.1322641838000@Atlassian.JIRA>
	<JIRA.12453411.1322641838000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453411.1322641838000.38563.1442469081836@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-276:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Clustering/multi-node tests cannot be run with -Djpda debugger
> --------------------------------------------------------------
>
>                 Key: WFLY-276
>                 URL: https://issues.jboss.org/browse/WFLY-276
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Documentation, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> The doc now says whats pasted below, but I am not sure if both servers are listening on 8787 because (that would fail the startup), if I have to connect to both or where do I configure that, etc.
> {code}
> Running JBoss AS instances with debugger
> Adding -Djpda (May be changed to -Ddebug in the future) will make JBoss AS run with JPDA JVM arguments for debugging.
> It will suspend and wait for the debugger to connect at port 8787.
> JBoss AS is started by Arquillian, when the first test which requires given instance is run. There's (currently) no challenge text in the console, it will look like the first test is stuck. This is being solved in http://jira.codehaus.org/browse/SUREFIRE-781.
> Depending on which test group(s) you run, multiple instances may be started. In that case, you need to attach the debugger multiple times.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:21 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:21 -0400 (EDT)
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.38567.1442469081924@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-264:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> 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
>             Fix For: 10.0.0.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:22 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-224) Add allowed values for
 attribute "cache-type" in "/subsystem=security/security-domain=*"
In-Reply-To: <JIRA.12486710.1362660680000@Atlassian.JIRA>
References: <JIRA.12486710.1362660680000@Atlassian.JIRA>
	<JIRA.12486710.1362660680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486710.1362660680000.38571.1442469082051@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-224:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Add allowed values for attribute "cache-type" in "/subsystem=security/security-domain=*"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-224
>                 URL: https://issues.jboss.org/browse/WFLY-224
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Harald Pehl
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> The attribute "cache-type" in "/subsystem=security/security-domain=*" can either be "default" or "infinispan". Please add the allowed value to the resource description. 
> In order to generate the UI based on the management model, it is essential that information like this is present.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:22 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-210) Point to explicit security doc
 in server.log
In-Reply-To: <JIRA.12450346.1319565767000@Atlassian.JIRA>
References: <JIRA.12450346.1319565767000@Atlassian.JIRA>
	<JIRA.12450346.1319565767000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450346.1319565767000.38576.1442469082247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-210:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Point to explicit security doc in server.log
> --------------------------------------------
>
>                 Key: WFLY-210
>                 URL: https://issues.jboss.org/browse/WFLY-210
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Server
>         Environment: Thinkpad T510 w/ 4 cores, 8Gb, running CSB
>            Reporter: Chuck Mosher
>            Assignee: Darran Lofthouse
>            Priority: Minor
>              Labels: eap6-ux
>             Fix For: 10.0.0.CR2
>
>
> Nice to warn me (in the server.log) that I have a security issue due to the cluster admin/user pwd using the defaults.  Warning tells me to look at the docs; would it be possible to put it the hyperlink to the specific doc?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 01:51:22 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 17 Sep 2015 01:51:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-80) Product Version should not
 prepend product name with JBoss
In-Reply-To: <JIRA.12487209.1363252404000@Atlassian.JIRA>
References: <JIRA.12487209.1363252404000@Atlassian.JIRA>
	<JIRA.12487209.1363252404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487209.1363252404000.38581.1442469082367@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-80:
-----------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Product Version should not prepend product name with JBoss
> ----------------------------------------------------------
>
>                 Key: WFLY-80
>                 URL: https://issues.jboss.org/browse/WFLY-80
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: NadirX
>            Assignee: Jason Greene
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> version/src/main/java/org/jboss/as/version/ProductConfig.java prepends the Product Name with 'JBoss' which is inappropriate for community projects. The result is that at startup I get the following
> "INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms"
> where instead I should see 
> "INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 02:48:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Thu, 17 Sep 2015 02:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5353) Unable to set resolve-hosts
	for access-log
In-Reply-To: <JIRA.12585103.1442406697000@Atlassian.JIRA>
References: <JIRA.12585103.1442406697000@Atlassian.JIRA>
	<JIRA.12585103.1442406697000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585103.1442406697000.38646.1442472480414@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109737#comment-13109737 ] 

Radim Hatlapatka commented on WFLY-5353:
----------------------------------------

I agree with you and believe that setting it on the connector should be enough.

> Unable to set resolve-hosts for access-log
> ------------------------------------------
>
>                 Key: WFLY-5353
>                 URL: https://issues.jboss.org/browse/WFLY-5353
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> In previous versions of EAP (Web subsystem) there was possible to enable resolving hosts for access logging. This is not possible to enable with Undertow.
> Steps for enabling in JBoss Web:
> This was accomplished by setting {{resolve-hosts}} attribute of access-log to {{true}} ({{/subsystem=web/virtual-server=default-host/configuration=access-log:add(resolve-hosts=true)}}) and enabling lookups for connector ({{/subsystem=web/connector=http:write-attribute(name=enable-lookups, value=true)}}).
> In Undertow subsystem there is only possible to enable resolving peer address ({{/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=resolve-peer-address, value=true)}}), which doesn't have by itself any impact on output in access-log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 03:05:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 17 Sep 2015 03:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when
 adding large deployment with audit logging enabled
In-Reply-To: <JIRA.12571787.1431651101000@Atlassian.JIRA>
References: <JIRA.12571787.1431651101000@Atlassian.JIRA>
	<JIRA.12571787.1431651101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571787.1431651101000.38661.1442473500394@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109742#comment-13109742 ] 

Alexey Loubyansky commented on WFCORE-695:
------------------------------------------

Bytes are attached only when deploy command is used in CLI batches. Otherwise, it's streams.

> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-695
>                 URL: https://issues.jboss.org/browse/WFCORE-695
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 1.0.0.CR4
>            Reporter: James Livingston
>            Assignee: Alexey Loubyansky
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
>         at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
>         at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
>         at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 04:27:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 17 Sep 2015 04:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212)
 java.lang.StringIndexOutOfBoundsException during deployment of war with
 specific ejb jar descriptor
In-Reply-To: <JIRA.12556556.1415025535000@Atlassian.JIRA>
References: <JIRA.12556556.1415025535000@Atlassian.JIRA>
	<JIRA.12556556.1415025535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556556.1415025535000.38982.1442478420520@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109777#comment-13109777 ] 

Jeff Mesnil commented on WFCORE-212:
------------------------------------

This is caused by an issue in HornetQ RA that does not validate its activation spec. Having a durable subscription without a clientId results in an invalid MDB.

I don't think we should change anything in the PathElement. It will only allow the server to go a bit further but the MDB will still not be able to deploy correctly.

I have opened a corresponding issues for Artemis (using in WildFly 10) https://issues.apache.org/jira/browse/ARTEMIS-225
Since HornetQ is not in maintenance mode only, it is unlikely they will fix this issue. 

> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-212
>                 URL: https://issues.jboss.org/browse/WFCORE-212
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Brian Stansberry
>         Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
>        <activation-config-property>
>           <activation-config-property-name>subscriptionDurability</activation-config-property-name>
>           <activation-config-property-value>Durable</activation-config-property-value>
>         </activation-config-property>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 04:39:00 2015
From: issues at jboss.org (Thomas Leung (JIRA))
Date: Thu, 17 Sep 2015 04:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.39062.1442479140141@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109788#comment-13109788 ] 

Thomas Leung commented on DROOLS-890:
-------------------------------------

Sorry for late reply. I mentioned ClassNotFoundException because as my reply on 04/Sep/15 10:50 AM said, the deadlock happened after ClassNotFoundException is detected in org.drools.core.common.ProjectClassLoader.java:284. In this line, the method tries to lock 

        protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
            try {
                return loadType(name, resolve);
            } catch (ClassNotFoundException cnfe) {    <== it must throw ClassNotFoundException here and then reach line 284
                synchronized(projectClassLoader) {     <== wait for lock projectClassLoader
                    try {
                        return projectClassLoader.internalLoadClass(name, resolve);           // line 284
                    } catch (ClassNotFoundException cnfe2) {
                        return projectClassLoader.tryDefineType(name, cnfe);
                    }
                }
            }
        }

Here is the stacks, forgive my masking our part:

"CacheWorker:48" id=538 State:DEADLOCKED
	at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader.java:284)
	-  waiting to lock org.drools.core.common.ProjectClassLoader at 28572e93 owned by:"CacheWorker:31" id=521
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at ......(Masked)......
	at ConditionEvaluator86102d62aa004ffa871398c07ca154fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:216)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:173)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:251)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:367)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:286)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:139)
	at org.drools.core.command.runtime.rule.InsertElementsCommand.execute(InsertElementsCommand.java:93)
	at org.drools.core.command.runtime.rule.InsertElementsCommand.execute(InsertElementsCommand.java:40)
	at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
	at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:321)
	at ......(Masked)......
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$Storage.invoke(PartitionedCache.CDB:10)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache.onInvokeRequest(PartitionedCache.CDB:38)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$InvokeRequest.run(PartitionedCache.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:32)
	at com.tangosol.coherence.component.util.DaemonPool$Daemon.onNotify(DaemonPool.CDB:66)
	at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:51)
	at java.lang.Thread.run(Thread.java:724)

	Locked synchronizers:
	java.util.concurrent.locks.ReentrantLock$NonfairSync at 1ed66b58
	java.util.concurrent.locks.ReentrantLock$NonfairSync at 20ba2cd9

"CacheWorker:31" id=521 State:DEADLOCKED
	at java.lang.ClassLoader.loadClass(ClassLoader.java:404)
	-  waiting to lock org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader at 74793783 owned by:"CacheWorker:48" id=538
	at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadType(ProjectClassLoader.java:293)
	at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.access$200(ProjectClassLoader.java:258)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:140)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:115)
	-  locked org.drools.core.common.ProjectClassLoader at 28572e93
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:121)
	at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:45)
	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:85)
	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:72)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:171)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1430)
	at org.drools.core.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:222)
	at org.drools.core.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:216)
	at ......(Masked)......
	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1046)
	-  locked org.drools.core.common.DefaultAgenda at 7f928335
	at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:152)
	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:94)
	-  locked org.drools.core.phreak.RuleExecutor at 794de699
	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:964)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1234)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1239)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1222)
	at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:104)
	at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
	at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
	at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:321)
	at ......(Masked)......
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$Storage.invoke(PartitionedCache.CDB:10)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache.onInvokeRequest(PartitionedCache.CDB:38)
	at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$InvokeRequest.run(PartitionedCache.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:1)
	at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:32)
	at com.tangosol.coherence.component.util.DaemonPool$Daemon.onNotify(DaemonPool.CDB:66)
	at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:51)
	at java.lang.Thread.run(Thread.java:724)

	Locked synchronizers:
	java.util.concurrent.locks.ReentrantLock$NonfairSync at 695e8506

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 05:23:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 17 Sep 2015 05:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.39345.1442481780476@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109827#comment-13109827 ] 

Mario Fusco commented on DROOLS-890:
------------------------------------

There are a few things to be noted here:

# Thread "CacheWorker:48" is clearly waiting to lock the ProjectClassLoader because "CacheWorker:31" is holding it. However I don't understand why "CacheWorker:31" is waiting to lock the InternalTypesClassLoader since there's no thread holding that lock in the stacks you pasted (unless it isn't in the part you masked?) so I still don't see what is causing the deadlock.
# I have no idea why the evaluation of an alpha node constraint should invoke the ClassLoader as it is happening in thread "CacheWorker:48" and you're still masking the stack there. Could you please at least share the constraint that is doing this? In general, unless I'm not missing something, I believe that invoking the ClassLoader from inside the constraint is a really bad idea.
# This execution pattern cannot happen in drools 6.3+ because now inserts are enqueued and processed during the fireAllRules instead of being processed directly at insertion time as it happened in drools 6.2. For this reason I believe that this deadlock should be go gone anyway. 

Given the last point I'd be tempted to close again this issue, but I'll leave it open because I still don't have a complete understanding of what's going on there. Please clarify my doubts.



> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 05:27:00 2015
From: issues at jboss.org (David virgil naranjo (JIRA))
Date: Thu, 17 Sep 2015 05:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-796) Native maven pom parser
 doesn't work under OSGi
In-Reply-To: <JIRA.12573129.1432818035000@Atlassian.JIRA>
References: <JIRA.12573129.1432818035000@Atlassian.JIRA>
	<JIRA.12573129.1432818035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573129.1432818035000.39387.1442482020349@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109831#comment-13109831 ] 

David virgil naranjo commented on DROOLS-796:
---------------------------------------------

 I ve already tested the functionality on EAP 6.4, and Bxms 6.2. The use case is working

This is what I did:

1. Configure EAP 6.4 to use Fuse-bxms-integ. What I do is to use the Jboss eap 6.4 folder that is generated in the itests folder:

https://github.com/jboss-integration/fuse-bxms-integ/tree/master/release/eap/itests

2. Then it is important to make it working to set the M2_HOME:

export M2_HOME=$
{YOUR MAVEN HOME}

3. Modify the container quickstart to scan for updates:
https://github.com/jboss-integration/fuse-bxms-integ/tree/master/quickstarts/switchyard-rules-interview-container

4. For doing that it is required:

    Import the project in eclipse.
    Edit the src/main/resources/META-INF/switchyard.xml
    Check the checkbox scan for updates
    Include a release id, setting the groupId, artifactId and versionId. Use the same releaseId that is included in the pom.xml

5. Start Jboss EAP 6.4

6. mvn clean install -Pdeploy -Dmaven.test.skip=true

7. Modify the swithcyard.xml and uncheck the scan for updates (this is because the junit tests are failing in this case).

8. mvn clean install

9. mvn exec:java

10. Modify the drl file and in the System.out include something else.

11. mvn clean install

12. After one minute you ll see in the jboss logs that the artifact has been updated

13. mvn exec:java

14. Chekc the jboss logs and you ll see that the change has been updated.

> Native maven pom parser doesn't work under OSGi
> -----------------------------------------------
>
>                 Key: DROOLS-796
>                 URL: https://issues.jboss.org/browse/DROOLS-796
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>         Attachments: switchyard-example-rules-kie.zip
>
>
> The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases.
> In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo:
> https://gist.github.com/dvirgiln/e5c69afc7434367e04c1
> This is executed on EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 05:27:00 2015
From: issues at jboss.org (David virgil naranjo (JIRA))
Date: Thu, 17 Sep 2015 05:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-796) Native maven pom parser
 doesn't work under OSGi
In-Reply-To: <JIRA.12573129.1432818035000@Atlassian.JIRA>
References: <JIRA.12573129.1432818035000@Atlassian.JIRA>
	<JIRA.12573129.1432818035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573129.1432818035000.39391.1442482020441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David virgil naranjo resolved DROOLS-796.
-----------------------------------------
    Resolution: Done


> Native maven pom parser doesn't work under OSGi
> -----------------------------------------------
>
>                 Key: DROOLS-796
>                 URL: https://issues.jboss.org/browse/DROOLS-796
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>         Attachments: switchyard-example-rules-kie.zip
>
>
> The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases.
> In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo:
> https://gist.github.com/dvirgiln/e5c69afc7434367e04c1
> This is executed on EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 05:27:00 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 17 Sep 2015 05:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-986) Add-user script should
 reject weak passwords
In-Reply-To: <JIRA.12585195.1442481956000@Atlassian.JIRA>
References: <JIRA.12585195.1442481956000@Atlassian.JIRA>
	<JIRA.12585195.1442481956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585195.1442481956000.39393.1442482020495@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? moved JBEAP-1095 to WFCORE-986:
---------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-986  (was: JBEAP-1095)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Scripts
                           (was: Scripts)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.Beta4
                           (was: 7.0.0.DR9)


> Add-user script should reject weak passwords
> --------------------------------------------
>
>                 Key: WFCORE-986
>                 URL: https://issues.jboss.org/browse/WFCORE-986
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> *Description of problem:*
> Add-user script should reject weak passwords. Users should use stronger passwords to improve security. Restriction of password should be same as in EAP 6.4.x.
> * Restriction policy is defined in jboss-eap-7.0/bin/add-user.properties
> ** {{password.restriction=WARN}} should be replaced by {{password.restriction=REJECT}}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./add-user.sh -u ccc -p ddd -s
> *Actual results:*
> No error.
> *Expected results:*
> {noformat}WFLYDM0053: Password must have at least 8 characters!{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 17 05:47:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 17 Sep 2015 05:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-918) Janino java compiler issue
In-Reply-To: <JIRA.12585177.1442458941000@Atlassian.JIRA>
References: <JIRA.12585177.1442458941000@Atlassian.JIRA>
	<JIRA.12585177.1442458941000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585177.1442458941000.39499.1442483220157@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109842#comment-13109842 ] 

Mario Fusco commented on DROOLS-918:
------------------------------------

The name org$u46$drools$u46$bpmn2$u46$fc1291c5$u45$c25c$u45$4c6b$u45$aba3$u45$76efdcd16136_$u43$2014$u45$03$u45$07_13$u58$06$u58$29$u45$0800 is a valid Java identifier so I don't see why JANINO should have any problem with it. Can you please send a reproducer for this problem?

Also consider that we are about to deprecate and remove the JANINO compiler. Is there any specific reason why you want to use it? 



> Janino java compiler issue
> --------------------------
>
>                 Key: DROOLS-918
>                 URL: https://issues.jboss.org/browse/DROOLS-918
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.2.0.Final
>            Reporter: sam dai
>            Assignee: Mario Fusco
>
> Recently I upgraded drools from version 6.0.0 Final to version 6.2.0 Final, I found some bpm process can't be deployed, the error message is as below.
> {color:#d04437}java.lang.IllegalArgumentException: Errors while parsing knowledge base + errors added Unable to generate action invoker. Unknown variable or type "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687"
> A method named "action1" is not declared in any enclosing class nor any supertype, nor through a static import
> Expression "Process_org$u46$drools$u46$bpmn2$u46$90f495e7$u45$788b$u45$472c$u45$abb3$u45$b37125d5a81e_$u43$_2014$u45$06$u45$18_05$u58$40$u58$29_$u45$0700162982687" is not an rvalue{color}
> The java compiler is "JANINO" by setting the value of system property "drools.dialect.java.compiler" as "JANINO".  If I use ECLIPSE java compiler, will not have this issue. I debugged the code, found code of line 82 of org.drools.compiler.rule.builder.dialect.DialectUtil.java is changed from
> {color:#205081}final String newName = prefix + "_" + NON_ALPHA_REGEX.matcher(name).replaceAll("_");{color}
> to 
> {color:#205081}final String newName = prefix + "_" + normalizeRuleName( name );{color}
> If I changed it back, bpm process can be deployed successfully.
> Then I did more testing. for a name "org.drools.bpmn2.fc1291c5-c25c-4c6b-aba3-76efdcd16136 + 2014-03-07 13:06:29 -0800", 
> if I use script "normalizeRuleName( name )", the value will be "org$u46$drools$u46$bpmn2$u46$fc1291c5$u45$c25c$u45$4c6b$u45$aba3$u45$76efdcd16136_$u43$_2014$u45$03$u45$07_13$u58$06$u58$29_$u45$0800", 
> if use script "NON_ALPHA_REGEX.matcher(name).replaceAll("_");", the value will be 
> "org_drools_bpmn2_fc1291c5_c25c_4c6b_aba3_76efdcd16136___2014_03_07_13_06_29__0800"
> So I wonder if this is a bug or I missed some configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 05:51:00 2015
From: issues at jboss.org (Thomas Leung (JIRA))
Date: Thu, 17 Sep 2015 05:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.39534.1442483460701@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109847#comment-13109847 ] 

Thomas Leung commented on DROOLS-890:
-------------------------------------

1. This part I'm also in doubt but surely the lock was not masked by me.
2. That constraint I may have mentioned in my comment on 04/Sep/15 11:02 AM. 
    We eval a local function and that function calls another local function.
    These functions are doing string manipulation only so I have no idea why this will invoke ClassLoader.
    What I guess is that after compilation the functions become a separate Java class. It may have problem loading such function class?
    I am not expert in Drools so I just guess what Drools internally does by decompiling it and observed.

For point 2, we tried merging the 2nd function into the 1st function (so that no more sub-call in 1st function), and the DEADLOCK issue is gone.
But if that is the cause, it is quite inconvenient if there is such limitation to the functions call.


> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 07:32:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 17 Sep 2015 07:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-533) Add blocking option to
 reload command for standalone server
In-Reply-To: <JIRA.12562434.1423065972000@Atlassian.JIRA>
References: <JIRA.12562434.1423065972000@Atlassian.JIRA>
	<JIRA.12562434.1423065972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562434.1423065972000.39924.1442489520338@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109900#comment-13109900 ] 

Alexey Loubyansky commented on WFCORE-533:
------------------------------------------

This is practically a duplicate of WFCORE-876. Once WFCORE-876 is fixed, this issues can be closed with the suggestion to use reload instead of :reload.

> Add blocking option to reload command for standalone server
> -----------------------------------------------------------
>
>                 Key: WFCORE-533
>                 URL: https://issues.jboss.org/browse/WFCORE-533
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Tomas Rohovsky
>            Assignee: Alexey Loubyansky
>
> reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
> {code}
> if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
>         /subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
>         :reload
> end-if
> {code}
> I use jboss-as-maven-plugin for its execution and sometimes I get: {{Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}}
> This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 08:37:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Sep 2015 08:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1965) Change default thread pool
 rejection policy to "abort"
In-Reply-To: <JIRA.12585135.1442416765000@Atlassian.JIRA>
References: <JIRA.12585135.1442416765000@Atlassian.JIRA>
	<JIRA.12585135.1442416765000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585135.1442416765000.40285.1442493420235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1965:
---------------------------
    Fix Version/s: 3.6.7


> Change default thread pool rejection policy to "abort"
> ------------------------------------------------------
>
>                 Key: JGRP-1965
>                 URL: https://issues.jboss.org/browse/JGRP-1965
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.6
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 3.6.7
>
>
> Currently, JGroups transport thread pools use discard as a rejection policy.  Thus if there are no available threads, and the queue is full, the executor will silently drop the task.
> Abort will throw a RejectedExecutionException, in which case, which JGroups catches to populate the num_rejected_msgs statistic.  This is a better default, so that users can monitor this value to determine whether or not to modify their thread pool configuration.  Otherwise, num_rejected_msgs is 0, which might be a source of confusion.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 08:45:01 2015
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 17 Sep 2015 08:45:01 -0400 (EDT)
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.40323.1442493901010@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated WFLY-3290:
--------------------------------------
    Fix Version/s: 10.0.0.CR1
                       (was: 10.0.0.CR2)


> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 08:49:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Sep 2015 08:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-868) CLI if/else is not handling
 special characters strings with parenthesis
In-Reply-To: <JIRA.12580331.1438762375000@Atlassian.JIRA>
References: <JIRA.12580331.1438762375000@Atlassian.JIRA>
	<JIRA.12580331.1438762375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580331.1438762375000.40349.1442494140484@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109972#comment-13109972 ] 

RH Bugzilla Integration commented on WFCORE-868:
------------------------------------------------

Tomas Hofman <thofman at redhat.com> changed the Status of [bug 1249773|https://bugzilla.redhat.com/show_bug.cgi?id=1249773] from ASSIGNED to POST

> CLI if/else is not handling special characters strings with parenthesis
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-868
>                 URL: https://issues.jboss.org/browse/WFCORE-868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Tomas Hofman
>            Assignee: Alexey Loubyansky
>             Fix For: 2.0.0.Beta7
>
>
> When using CLI if-else scripting that uses a string that contains parenthesis it fails with the following message:
> Failed to handle 'if (outcome == success && result.value != "a64180c0)e7187af86b435229de904104") of /system-property=test:read-resource': Unexpected operation at 49 in '(outcome == success && result.value != "a64180c0)e7187af86b435229de904104")'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 09:32:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 17 Sep 2015 09:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.40561.1442496720137@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110000#comment-13110000 ] 

Edson Tirelli commented on DROOLS-880:
--------------------------------------

As I mentioned above, I can't reproduce the problems you mentioned. I believe the problem is a misconfiguration on your test environment. 

We are working on the documentation of the new server. Also, maciej is creating a series of tutorial blog posts on how to configure and use the kie-server. You can find them here:

http://mswiderski.blogspot.ca/2015/09/unified-kie-execution-server-part-1.html

http://mswiderski.blogspot.ca/2015/09/unified-kie-execution-server-part-2.html

http://mswiderski.blogspot.ca/2015/09/unified-kie-execution-server-part-3.html



> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 17 09:34:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Thu, 17 Sep 2015 09:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-980) The capability registry
 fails to rollback properly
In-Reply-To: <JIRA.12585007.1442341852000@Atlassian.JIRA>
References: <JIRA.12585007.1442341852000@Atlassian.JIRA>
	<JIRA.12585007.1442341852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585007.1442341852000.40574.1442496840181@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110003#comment-13110003 ] 

ehsavoie Hugonnet commented on WFCORE-980:
------------------------------------------

https://github.com/wildfly/wildfly-core/pull/1076 for a simple test

> The capability registry fails to rollback properly
> --------------------------------------------------
>
>                 Key: WFCORE-980
>                 URL: https://issues.jboss.org/browse/WFCORE-980
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta7
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> If we register an already registered capability at a new RegistrationPoint and the operation rollbacks the registry still has the new RegistrationPoint.
> The publishedFullRegistry should be a deep copy of the registry:
> Reproducer working with the WFCORE-949 pr:
> {code:java}
> /socket-binding-group=standard-sockets/socket-binding=management-native:add(port=9999, interface=management)
> /core-service=management/management-interface=native-interface:add(socket-binding=native-management, security-realm=ManagementRealm) 
> /core-service=management/management-interface=native-interface:add(socket-binding=management-native, security-realm=ManagementRealm)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 09:46:01 2015
From: issues at jboss.org (Danila  Sofinskii (JIRA))
Date: Thu, 17 Sep 2015 09:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBCL-187) XML descriptors don't work in
 static deployment.
In-Reply-To: <JIRA.12585253.1442497519000@Atlassian.JIRA>
References: <JIRA.12585253.1442497519000@Atlassian.JIRA>
	<JIRA.12585253.1442497519113@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585253.1442497519000.40646.1442497561907@Atlassian.JIRA>

Danila  Sofinskii created JBCL-187:
--------------------------------------

             Summary: XML descriptors don't work in static deployment.
                 Key: JBCL-187
                 URL: https://issues.jboss.org/browse/JBCL-187
             Project: JBoss ClassLoader
          Issue Type: Feature Request
          Components: ClassLoader
            Reporter: Danila  Sofinskii
            Assignee: Ales Justin


I have one module with stateless EJB bean and two configuration files - persistence.xml and ejb-jar.xml in META-INF.
I try to deploy it in static context with jar index, created by Jandex, inside. For depends dynamically deployed modules I wrote 'Dependencies: core.module.name annotations' to manifest file, like in this issue: https://issues.jboss.org/browse/WFLY-4386
My bean found by WELD, but it can't take xml files - Persistence Context, which I configure in persistence.xml, not found, and Module Name from ejb-jar.xml are wrong, too.
How I can configure module for work with this xml files?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 09:48:00 2015
From: issues at jboss.org (Danila  Sofinskii (JIRA))
Date: Thu, 17 Sep 2015 09:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBCL-187) XML descriptors don't work in
 static deployment.
In-Reply-To: <JIRA.12585253.1442497519000@Atlassian.JIRA>
References: <JIRA.12585253.1442497519000@Atlassian.JIRA>
	<JIRA.12585253.1442497519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585253.1442497519000.40669.1442497680381@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBCL-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Danila  Sofinskii updated JBCL-187:
-----------------------------------
    Issue Type: Bug  (was: Feature Request)


> XML descriptors don't work in static deployment.
> ------------------------------------------------
>
>                 Key: JBCL-187
>                 URL: https://issues.jboss.org/browse/JBCL-187
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Danila  Sofinskii
>            Assignee: Ales Justin
>
> I have one module with stateless EJB bean and two configuration files - persistence.xml and ejb-jar.xml in META-INF.
> I try to deploy it in static context with jar index, created by Jandex, inside. For depends dynamically deployed modules I wrote 'Dependencies: core.module.name annotations' to manifest file, like in this issue: https://issues.jboss.org/browse/WFLY-4386
> My bean found by WELD, but it can't take xml files - Persistence Context, which I configure in persistence.xml, not found, and Module Name from ejb-jar.xml are wrong, too.
> How I can configure module for work with this xml files?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 09:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 09:52:00 -0400 (EDT)
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.40674.1442497920169@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: 3.0.0.Alpha1
                       (was: 2.0.0.CR2)


> "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: 2.0.0.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 09:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 09:52:00 -0400 (EDT)
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.40676.1442497920224@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: 2.0.0.CR2
                       (was: 3.0.0.Alpha1)


> "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: 2.0.0.CR2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 09:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 09:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-785) Improve capability related
	error messages
In-Reply-To: <JIRA.12576642.1435679852000@Atlassian.JIRA>
References: <JIRA.12576642.1435679852000@Atlassian.JIRA>
	<JIRA.12576642.1435679852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576642.1435679852000.40681.1442497920322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-785:
------------------------------------
    Fix Version/s: 3.0.0.Beta1
                       (was: 2.0.0.CR2)


> Improve capability related error messages
> -----------------------------------------
>
>                 Key: WFCORE-785
>                 URL: https://issues.jboss.org/browse/WFCORE-785
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta1
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:10:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Sep 2015 10:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to
 domain-management module
In-Reply-To: <JIRA.12553769.1412093571000@Atlassian.JIRA>
References: <JIRA.12553769.1412093571000@Atlassian.JIRA>
	<JIRA.12553769.1412093571000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553769.1412093571000.40836.1442499000238@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-137:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR2)


> Add Kerberos tests to domain-management module
> ----------------------------------------------
>
>                 Key: WFCORE-137
>                 URL: https://issues.jboss.org/browse/WFCORE-137
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:12:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Sep 2015 10:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to
 domain-management module
In-Reply-To: <JIRA.12553769.1412093571000@Atlassian.JIRA>
References: <JIRA.12553769.1412093571000@Atlassian.JIRA>
	<JIRA.12553769.1412093571000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553769.1412093571000.40842.1442499120298@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-137:
------------------------------------
        Parent:     (was: WFCORE-103)
    Issue Type: Task  (was: Sub-task)


> Add Kerberos tests to domain-management module
> ----------------------------------------------
>
>                 Key: WFCORE-137
>                 URL: https://issues.jboss.org/browse/WFCORE-137
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:14:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Sep 2015 10:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-103) Add Full Kerberos Support
In-Reply-To: <JIRA.12467133.1337768128000@Atlassian.JIRA>
References: <JIRA.12467133.1337768128000@Atlassian.JIRA>
	<JIRA.12467133.1337768128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467133.1337768128000.40857.1442499240886@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-103.
-------------------------------------
    Resolution: Done


Sub tasks all resolved in a previous release.

> Add Full Kerberos Support
> -------------------------
>
>                 Key: WFCORE-103
>                 URL: https://issues.jboss.org/browse/WFCORE-103
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: management_security,
>             Fix For: 2.0.0.CR2
>
>
> There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:14:01 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Thu, 17 Sep 2015 10:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3964) EJBAccessException is not
 returned to remote client
In-Reply-To: <JIRA.12554771.1412929454000@Atlassian.JIRA>
References: <JIRA.12554771.1412929454000@Atlassian.JIRA>
	<JIRA.12554771.1412929454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554771.1412929454000.40875.1442499241357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned WFLY-3964:
----------------------------------------

    Assignee: Dmitrii Tikhomirov


> EJBAccessException is not returned to remote client
> ---------------------------------------------------
>
>                 Key: WFLY-3964
>                 URL: https://issues.jboss.org/browse/WFLY-3964
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>            Reporter: Dirk Weil
>            Assignee: Dmitrii Tikhomirov
>
> When calling an EJB method with access restrictions via @RolesAllowed from a remote client with unsufficient user priveledges, an EJBAccessException should be returned to the remote caller. WildFly returns a java.io.StreamCorruptedException instead.
> Stacktrace on client:
> {code}
> java.io.StreamCorruptedException: Unexpected byte found when reading an object: 0
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:236)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> 	at com.sun.proxy.$Proxy6.restrictedMethod(Unknown Source)
> 	at de.gedoplan.beantrial.wildflyejbremote.DemoTest.testRestrictedMethod(DemoTest.java:68)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)
> 	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.io.StreamCorruptedException: Unexpected byte found when reading an object: 0
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:751)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> 	at org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments(ProtocolMessageHandler.java:55)
> 	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:82)
> 	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.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> 	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:202)
> 	... 30 more
> 	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> 	at org.junit.Assert.assertThat(Assert.java:865)
> 	at org.junit.Assert.assertThat(Assert.java:832)
> 	at org.junit.rules.ExpectedException.handleException(ExpectedException.java:198)
> 	at org.junit.rules.ExpectedException.access$500(ExpectedException.java:85)
> 	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:177)
> 	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:23:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Sep 2015 10:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-646) Product to Project Schema
	and Model Sync
In-Reply-To: <JIRA.12568717.1429281526000@Atlassian.JIRA>
References: <JIRA.12568717.1429281526000@Atlassian.JIRA>
	<JIRA.12568717.1429281526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568717.1429281526000.40962.1442499780518@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-646.
-------------------------------------
    Resolution: Done


All sub tasks resolved.

> Product to Project Schema and Model Sync
> ----------------------------------------
>
>                 Key: WFCORE-646
>                 URL: https://issues.jboss.org/browse/WFCORE-646
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> Periodic sync of EAP schemas with WildFly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:32:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 17 Sep 2015 10:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5356) Upgrade Artemis 1.1.0
In-Reply-To: <JIRA.12585258.1442500262000@Atlassian.JIRA>
References: <JIRA.12585258.1442500262000@Atlassian.JIRA>
	<JIRA.12585258.1442500262925@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585258.1442500262000.41036.1442500320307@Atlassian.JIRA>

Jeff Mesnil created WFLY-5356:
---------------------------------

             Summary: Upgrade Artemis 1.1.0
                 Key: WFLY-5356
                 URL: https://issues.jboss.org/browse/WFLY-5356
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 10.0.0.CR2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:32:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 17 Sep 2015 10:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5356) Upgrade Artemis 1.1.0
In-Reply-To: <JIRA.12585258.1442500262000@Atlassian.JIRA>
References: <JIRA.12585258.1442500262000@Atlassian.JIRA>
	<JIRA.12585258.1442500262000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585258.1442500262000.41045.1442500320649@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5356:
------------------------------
    Priority: Blocker  (was: Major)


> Upgrade Artemis 1.1.0
> ---------------------
>
>                 Key: WFLY-5356
>                 URL: https://issues.jboss.org/browse/WFLY-5356
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:32:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Sep 2015 10:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-278) Revisit error message for an
 authentication failure.
In-Reply-To: <JIRA.12536929.1396443828000@Atlassian.JIRA>
References: <JIRA.12536929.1396443828000@Atlassian.JIRA>
	<JIRA.12536929.1396443828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536929.1396443828000.41048.1442500320744@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-278.
-------------------------------------
    Resolution: Done


The linked updates mean that a more meaningful error message is now displayed: -


{noformat}
Password: Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: Authentication failed: all available authentication mechanisms failed:
   DIGEST-MD5: Server rejected authentication
{noformat}


> Revisit error message for an authentication failure.
> ----------------------------------------------------
>
>                 Key: WFCORE-278
>                 URL: https://issues.jboss.org/browse/WFCORE-278
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> After authentication fails in the CLI the following error message is output: -
> {code}
> Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms
> {code}
> This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 10:42:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 17 Sep 2015 10:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-919) Triggering an incremental
 compilation from inside a consequence causes a deadlock
In-Reply-To: <JIRA.12585260.1442500892000@Atlassian.JIRA>
References: <JIRA.12585260.1442500892000@Atlassian.JIRA>
	<JIRA.12585260.1442500892274@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585260.1442500892000.41144.1442500920409@Atlassian.JIRA>

Mario Fusco created DROOLS-919:
----------------------------------

             Summary: Triggering an incremental compilation from inside a consequence causes a deadlock
                 Key: DROOLS-919
                 URL: https://issues.jboss.org/browse/DROOLS-919
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


Triggering an incremental compilation (i.e. calling kieContainer.updateToVersion) from inside a rule consequence causes a deadlock because it attempts to update the read lock on the kbase acquired when invoking ksession.fireAllRules() to a write lock.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 11:14:01 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 17 Sep 2015 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-912) LdapExtLoginModule fails
 to load roles when a Custom Principal is specified
In-Reply-To: <JIRA.12475030.1348175635000@Atlassian.JIRA>
References: <JIRA.12475030.1348175635000@Atlassian.JIRA>
	<JIRA.12475030.1348175635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475030.1348175635000.41369.1442502841304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Derek Horton updated SECURITY-912:
----------------------------------
    Git Pull Request: https://github.com/picketbox/picketbox/pull/49


> LdapExtLoginModule fails to load roles when a Custom Principal is specified
> ---------------------------------------------------------------------------
>
>                 Key: SECURITY-912
>                 URL: https://issues.jboss.org/browse/SECURITY-912
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Jess Sightler
>            Assignee: Derek Horton
>
> LdapExtLoginModule.addRole(String) calls:
> super.createIdentity(roleName);
> This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
> The callchain is:
> createLdapInitContext->rolesSearch->addRole
> Lines 432 and 433 of LdapExtLoginModule are:
> if (currentTCCL != null)
>             SecurityActions.setContextClassLoader(null);
> This clears the classloader, so the principal class cannot be loaded.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 11:14:01 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 17 Sep 2015 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-912) LdapExtLoginModule fails
 to load roles when a Custom Principal is specified
In-Reply-To: <JIRA.12475030.1348175635000@Atlassian.JIRA>
References: <JIRA.12475030.1348175635000@Atlassian.JIRA>
	<JIRA.12475030.1348175635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475030.1348175635000.41373.1442502841474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Derek Horton reassigned SECURITY-912:
-------------------------------------

    Assignee: Stefan Guilhen  (was: Derek Horton)


> LdapExtLoginModule fails to load roles when a Custom Principal is specified
> ---------------------------------------------------------------------------
>
>                 Key: SECURITY-912
>                 URL: https://issues.jboss.org/browse/SECURITY-912
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Jess Sightler
>            Assignee: Stefan Guilhen
>
> LdapExtLoginModule.addRole(String) calls:
> super.createIdentity(roleName);
> This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
> The callchain is:
> createLdapInitContext->rolesSearch->addRole
> Lines 432 and 433 of LdapExtLoginModule are:
> if (currentTCCL != null)
>             SecurityActions.setContextClassLoader(null);
> This clears the classloader, so the principal class cannot be loaded.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 11:15:02 2015
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 17 Sep 2015 11:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-912) LdapExtLoginModule fails
 to load roles when a Custom Principal is specified
In-Reply-To: <JIRA.12475030.1348175635000@Atlassian.JIRA>
References: <JIRA.12475030.1348175635000@Atlassian.JIRA>
	<JIRA.12475030.1348175635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475030.1348175635000.41377.1442502902025@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110080#comment-13110080 ] 

Derek Horton commented on SECURITY-912:
---------------------------------------

Submitted a pull request to resolve this issue:
https://github.com/picketbox/picketbox/pull/49

> LdapExtLoginModule fails to load roles when a Custom Principal is specified
> ---------------------------------------------------------------------------
>
>                 Key: SECURITY-912
>                 URL: https://issues.jboss.org/browse/SECURITY-912
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Jess Sightler
>            Assignee: Stefan Guilhen
>
> LdapExtLoginModule.addRole(String) calls:
> super.createIdentity(roleName);
> This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
> The callchain is:
> createLdapInitContext->rolesSearch->addRole
> Lines 432 and 433 of LdapExtLoginModule are:
> if (currentTCCL != null)
>             SecurityActions.setContextClassLoader(null);
> This clears the classloader, so the principal class cannot be loaded.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 11:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 11:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-533) Add blocking option to
 reload command for standalone server
In-Reply-To: <JIRA.12562434.1423065972000@Atlassian.JIRA>
References: <JIRA.12562434.1423065972000@Atlassian.JIRA>
	<JIRA.12562434.1423065972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562434.1423065972000.41670.1442505540320@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110113#comment-13110113 ] 

Brian Stansberry commented on WFCORE-533:
-----------------------------------------

It's not a duplicate.

The problem here is the reporter is using the WildFly maven plugin, and the "reload" command will not work there because the plugin is providing a ModelControllerClient rather than letting the CLI create its own custom impl. I believe the if/end-if aspect of the original report is really a tangent. The basic issue is there is no safe way to do a reload from within the maven plugin.

I'll update the issue title to reflect this.

I could just move this to WFMP, but the WFCORE code has an issue. The code for embedding the CLI in another app allows the embedding app to provide the MCC, but the CLI can't fully function unless it controls the type of the MCC. So we either need to disable that ability for the embedding app to provide the MCC, or we need the basic MCC contract to provide all the hooks the CLI uses, and thus get rid of the CLI's custom impl.

> Add blocking option to reload command for standalone server
> -----------------------------------------------------------
>
>                 Key: WFCORE-533
>                 URL: https://issues.jboss.org/browse/WFCORE-533
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Tomas Rohovsky
>            Assignee: Alexey Loubyansky
>
> reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
> {code}
> if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
>         /subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
>         :reload
> end-if
> {code}
> I use jboss-as-maven-plugin for its execution and sometimes I get: {{Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}}
> This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 12:00:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 12:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-533) Handling of
 ModelControllerClient means there is no safe way to reload a process from
 the wildfly maven plugin
In-Reply-To: <JIRA.12562434.1423065972000@Atlassian.JIRA>
References: <JIRA.12562434.1423065972000@Atlassian.JIRA>
	<JIRA.12562434.1423065972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562434.1423065972000.41680.1442505601682@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-533:
------------------------------------
    Summary: Handling of ModelControllerClient means there is no safe way to reload a process from the wildfly maven plugin  (was: Add blocking option to reload command for standalone server)


> Handling of ModelControllerClient means there is no safe way to reload a process from the wildfly maven plugin
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-533
>                 URL: https://issues.jboss.org/browse/WFCORE-533
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Tomas Rohovsky
>            Assignee: Alexey Loubyansky
>
> reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
> {code}
> if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
>         /subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
>         :reload
> end-if
> {code}
> I use jboss-as-maven-plugin for its execution and sometimes I get: {{Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}}
> This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 14:37:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 17 Sep 2015 14:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-441) If possible,
 eliminate the NonTxEmCloser by closing the EM immediately after
 each EM invocation
In-Reply-To: <JIRA.12455914.1325826336000@Atlassian.JIRA>
References: <JIRA.12455914.1325826336000@Atlassian.JIRA>
	<JIRA.12455914.1325826336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455914.1325826336000.42206.1442515020163@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-441.
-----------------------------
    Resolution: Rejected


reopen this issue when its time to work on it

> If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-441
>                 URL: https://issues.jboss.org/browse/WFLY-441
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> For Queries, handoff the EntityManager to a Query object wrapper and have the Query object finalizer close the EntityManager.  
> Make sure that we respect JPA 2.0 section 3.8.6 (detach objects returned from Query object).
> 1.  Methods that return a Query, will hand off the EM to the Query object wrapper.
> 2.  Other methods will close the EM at the end of the EM method invocation.
> When making this change, make sure that performance doesn't degrade.  The cost of this change, will be that each (transaction scoped non-tx) EM invocation will create a new persistence context, but we can eliminate the NonTxEmCloser which has its own overhead.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 14:38:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 17 Sep 2015 14:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-441) If possible,
 eliminate the NonTxEmCloser by closing the EM immediately after
 each EM invocation
In-Reply-To: <JIRA.12455914.1325826336000@Atlassian.JIRA>
References: <JIRA.12455914.1325826336000@Atlassian.JIRA>
	<JIRA.12455914.1325826336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455914.1325826336000.42210.1442515080541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reopened WFLY-441:
-------------------------------
      Assignee: Scott Marlow


> If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-441
>                 URL: https://issues.jboss.org/browse/WFLY-441
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: 10.0.0.CR2
>
>
> For Queries, handoff the EntityManager to a Query object wrapper and have the Query object finalizer close the EntityManager.  
> Make sure that we respect JPA 2.0 section 3.8.6 (detach objects returned from Query object).
> 1.  Methods that return a Query, will hand off the EM to the Query object wrapper.
> 2.  Other methods will close the EM at the end of the EM method invocation.
> When making this change, make sure that performance doesn't degrade.  The cost of this change, will be that each (transaction scoped non-tx) EM invocation will create a new persistence context, but we can eliminate the NonTxEmCloser which has its own overhead.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 14:38:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 17 Sep 2015 14:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-441) If possible,
 eliminate the NonTxEmCloser by closing the EM immediately after
 each EM invocation
In-Reply-To: <JIRA.12455914.1325826336000@Atlassian.JIRA>
References: <JIRA.12455914.1325826336000@Atlassian.JIRA>
	<JIRA.12455914.1325826336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455914.1325826336000.42214.1442515080640@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-441:
------------------------------
    Fix Version/s:     (was: 10.0.0.CR2)


> If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-441
>                 URL: https://issues.jboss.org/browse/WFLY-441
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For Queries, handoff the EntityManager to a Query object wrapper and have the Query object finalizer close the EntityManager.  
> Make sure that we respect JPA 2.0 section 3.8.6 (detach objects returned from Query object).
> 1.  Methods that return a Query, will hand off the EM to the Query object wrapper.
> 2.  Other methods will close the EM at the end of the EM method invocation.
> When making this change, make sure that performance doesn't degrade.  The cost of this change, will be that each (transaction scoped non-tx) EM invocation will create a new persistence context, but we can eliminate the NonTxEmCloser which has its own overhead.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 14:38:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 17 Sep 2015 14:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-441) If possible,
 eliminate the NonTxEmCloser by closing the EM immediately after
 each EM invocation
In-Reply-To: <JIRA.12455914.1325826336000@Atlassian.JIRA>
References: <JIRA.12455914.1325826336000@Atlassian.JIRA>
	<JIRA.12455914.1325826336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455914.1325826336000.42224.1442515080811@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-441.
-----------------------------
    Resolution: Rejected


> If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-441
>                 URL: https://issues.jboss.org/browse/WFLY-441
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For Queries, handoff the EntityManager to a Query object wrapper and have the Query object finalizer close the EntityManager.  
> Make sure that we respect JPA 2.0 section 3.8.6 (detach objects returned from Query object).
> 1.  Methods that return a Query, will hand off the EM to the Query object wrapper.
> 2.  Other methods will close the EM at the end of the EM method invocation.
> When making this change, make sure that performance doesn't degrade.  The cost of this change, will be that each (transaction scoped non-tx) EM invocation will create a new persistence context, but we can eliminate the NonTxEmCloser which has its own overhead.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 14:55:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 14:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.42289.1442516100218@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110172#comment-13110172 ] 

Brian Stansberry commented on WFCORE-949:
-----------------------------------------

A possible workaround for this is to have the remove handlers for this and native-interface add a Stage.MODEL step to do a manual model validation. The step would check for the presence of the /subsystem=jmx/remoting-connector=jmx resource and if present, check for the presence of either /core-service=management/management-interface=native-interface or /core-service=management/management-interface=http-interface with http-upgrade=true.

The manual validation can be removed when the necessary capability stuff is done.

The handlers should put the process in restart-required; they shouldn't directly remove the services.



> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: ehsavoie Hugonnet
>              Labels: affects_elytron
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:15:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-987)
 java.lang.StringIndexOutOfBoundsException when empty string is used in a
 resource address value
In-Reply-To: <JIRA.12585297.1442517259000@Atlassian.JIRA>
References: <JIRA.12585297.1442517259000@Atlassian.JIRA>
	<JIRA.12585297.1442517259471@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585297.1442517259000.42341.1442517301248@Atlassian.JIRA>

Brian Stansberry created WFCORE-987:
---------------------------------------

             Summary: java.lang.StringIndexOutOfBoundsException when empty string is used in a resource address value
                 Key: WFCORE-987
                 URL: https://issues.jboss.org/browse/WFCORE-987
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
            Reporter: Tomas Remes
            Assignee: Brian Stansberry


Following steps to reproduce section you will encounter this exception:
{noformat}
15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
{noformat}

Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
{noformat}
       <activation-config-property>
          <activation-config-property-name>subscriptionDurability</activation-config-property-name>
          <activation-config-property-value>Durable</activation-config-property-value>
        </activation-config-property>
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:17:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-987)
 java.lang.StringIndexOutOfBoundsException when empty string is used in a
 resource address value
In-Reply-To: <JIRA.12585297.1442517259000@Atlassian.JIRA>
References: <JIRA.12585297.1442517259000@Atlassian.JIRA>
	<JIRA.12585297.1442517259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585297.1442517259000.42364.1442517420162@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-987:
------------------------------------
    Description: 
Following copied from WFCORE-212 shows a StringIndexOutOfBounds being thrown when the empty string is the 'value' passed to PathElement.pathElement(key, value). The point of this JIRA is not to correct the reason for that empty string, but rather to fail cleanly (probably with the same logic used for the value == null case.)

Following steps to reproduce section you will encounter this exception:
{noformat}
15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
{noformat}

  was:
Following steps to reproduce section you will encounter this exception:
{noformat}
15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
{noformat}

Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
{noformat}
       <activation-config-property>
          <activation-config-property-name>subscriptionDurability</activation-config-property-name>
          <activation-config-property-value>Durable</activation-config-property-value>
        </activation-config-property>
{noformat}



> java.lang.StringIndexOutOfBoundsException when empty string is used in a resource address value
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-987
>                 URL: https://issues.jboss.org/browse/WFCORE-987
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Brian Stansberry
>
> Following copied from WFCORE-212 shows a StringIndexOutOfBounds being thrown when the empty string is the 'value' passed to PathElement.pathElement(key, value). The point of this JIRA is not to correct the reason for that empty string, but rather to fail cleanly (probably with the same logic used for the value == null case.)
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:17:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-987)
 java.lang.StringIndexOutOfBoundsException when empty string is used in a
 resource address value
In-Reply-To: <JIRA.12585297.1442517259000@Atlassian.JIRA>
References: <JIRA.12585297.1442517259000@Atlassian.JIRA>
	<JIRA.12585297.1442517259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585297.1442517259000.42367.1442517420383@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-987:
------------------------------------
    Steps to Reproduce:   (was: 1. in $JBOSS_HOME/standalone/configurations/standalone-full.xml add jms topic to jms destinations:
{noformat}
                    <jms-topic name="testTopic">
                        <entry name="topic/test"/>
                        <entry name="java:jboss/exported/jms/topic/test"/>
                    </jms-topic>
{noformat}
2. Run WFLY full dist with ./bin/standalone.sh -c standalone-full.xml
3. Deploy attached war - notice the weird behavior
4. Try to restart the server)


> java.lang.StringIndexOutOfBoundsException when empty string is used in a resource address value
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-987
>                 URL: https://issues.jboss.org/browse/WFCORE-987
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Brian Stansberry
>
> Following copied from WFCORE-212 shows a StringIndexOutOfBounds being thrown when the empty string is the 'value' passed to PathElement.pathElement(key, value). The point of this JIRA is not to correct the reason for that empty string, but rather to fail cleanly (probably with the same logic used for the value == null case.)
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:18:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-987)
 java.lang.StringIndexOutOfBoundsException when empty string is used in a
 resource address value
In-Reply-To: <JIRA.12585297.1442517259000@Atlassian.JIRA>
References: <JIRA.12585297.1442517259000@Atlassian.JIRA>
	<JIRA.12585297.1442517259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585297.1442517259000.42372.1442517480351@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-987:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1


> java.lang.StringIndexOutOfBoundsException when empty string is used in a resource address value
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-987
>                 URL: https://issues.jboss.org/browse/WFCORE-987
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha1
>
>
> Following copied from WFCORE-212 shows a StringIndexOutOfBounds being thrown when the empty string is the 'value' passed to PathElement.pathElement(key, value). The point of this JIRA is not to correct the reason for that empty string, but rather to fail cleanly (probably with the same logic used for the value == null case.)
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:18:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-987)
 java.lang.StringIndexOutOfBoundsException when empty string is used in a
 resource address value
In-Reply-To: <JIRA.12585297.1442517259000@Atlassian.JIRA>
References: <JIRA.12585297.1442517259000@Atlassian.JIRA>
	<JIRA.12585297.1442517259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585297.1442517259000.42375.1442517480407@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-987:
---------------------------------------

    Assignee:     (was: Brian Stansberry)


> java.lang.StringIndexOutOfBoundsException when empty string is used in a resource address value
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-987
>                 URL: https://issues.jboss.org/browse/WFCORE-987
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>             Fix For: 3.0.0.Alpha1
>
>
> Following copied from WFCORE-212 shows a StringIndexOutOfBounds being thrown when the empty string is the 'value' passed to PathElement.pathElement(key, value). The point of this JIRA is not to correct the reason for that empty string, but rather to fail cleanly (probably with the same logic used for the value == null case.)
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:20:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212)
 java.lang.StringIndexOutOfBoundsException during deployment of war with
 specific ejb jar descriptor
In-Reply-To: <JIRA.12556556.1415025535000@Atlassian.JIRA>
References: <JIRA.12556556.1415025535000@Atlassian.JIRA>
	<JIRA.12556556.1415025535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556556.1415025535000.42391.1442517600500@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110186#comment-13110186 ] 

Brian Stansberry commented on WFCORE-212:
-----------------------------------------

[~jmesnil] Thanks. I've created WFCORE-987 to have PathElement provide a proper failure when this happens. I'll move this one over to WFLY Messaging component and assign to you.

> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-212
>                 URL: https://issues.jboss.org/browse/WFCORE-212
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 9.0.0.Final, 9.0.1.Final
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Brian Stansberry
>         Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
>        <activation-config-property>
>           <activation-config-property-name>subscriptionDurability</activation-config-property-name>
>           <activation-config-property-value>Durable</activation-config-property-value>
>         </activation-config-property>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:20:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5357)
 java.lang.StringIndexOutOfBoundsException during deployment of war with
 specific ejb jar descriptor
In-Reply-To: <JIRA.12556556.1415025535000@Atlassian.JIRA>
References: <JIRA.12556556.1415025535000@Atlassian.JIRA>
	<JIRA.12556556.1415025535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556556.1415025535000.42395.1442517600571@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFCORE-212 to WFLY-5357:
-----------------------------------------------

              Project: WildFly  (was: WildFly Core)
                  Key: WFLY-5357  (was: WFCORE-212)
          Component/s: JMS
                           (was: Domain Management)
    Affects Version/s: 9.0.1.Final
                       9.0.0.Final
                           (was: 1.0.0.Alpha9)
                           (was: 1.0.0.Alpha11)


> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5357
>                 URL: https://issues.jboss.org/browse/WFLY-5357
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 9.0.1.Final, 9.0.0.Final
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Brian Stansberry
>         Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
>        <activation-config-property>
>           <activation-config-property-name>subscriptionDurability</activation-config-property-name>
>           <activation-config-property-value>Durable</activation-config-property-value>
>         </activation-config-property>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:21:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5357)
 java.lang.StringIndexOutOfBoundsException during deployment of war with
 specific ejb jar descriptor
In-Reply-To: <JIRA.12556556.1415025535000@Atlassian.JIRA>
References: <JIRA.12556556.1415025535000@Atlassian.JIRA>
	<JIRA.12556556.1415025535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556556.1415025535000.42399.1442517660122@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-5357:
--------------------------------------

    Assignee: Jeff Mesnil  (was: Brian Stansberry)


> java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5357
>                 URL: https://issues.jboss.org/browse/WFLY-5357
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 9.0.0.Final, 9.0.1.Final
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: Jeff Mesnil
>         Attachments: test-jms.zip
>
>
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}
> Note that the attached WAR works fine when the following is removed from ejb-jar.xml:
> {noformat}
>        <activation-config-property>
>           <activation-config-property-name>subscriptionDurability</activation-config-property-name>
>           <activation-config-property-value>Durable</activation-config-property-value>
>         </activation-config-property>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:37:00 2015
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 17 Sep 2015 15:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4255) Allow Arquillian to specify a
 timeout value for the WildFly clean shutdown mechanism when shutting down a
 server
In-Reply-To: <JIRA.12561011.1421343439000@Atlassian.JIRA>
References: <JIRA.12561011.1421343439000@Atlassian.JIRA>
	<JIRA.12561011.1421343439000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561011.1421343439000.42443.1442518620415@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110194#comment-13110194 ] 

Richard Achmatowicz commented on WFLY-4255:
-------------------------------------------

This issue involved changes in arquillian-core and wildfly-arquillian, as well as the top level PR in WFLY.
The changes to arquillian-core are in 1.1.9.Final; the changes to wildfly-arquillian are in 1.1.0.Alpha1.
So, we are waiting for 1.1.0.Alpha1 to move to Final.
@jamezp some concerns about potential instability of the testsuite with this alpha version.




> Allow Arquillian to specify a timeout value for the WildFly clean shutdown mechanism when shutting down a server
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4255
>                 URL: https://issues.jboss.org/browse/WFLY-4255
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Radoslav Husar
>
> WildFly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete:
> {code}
> [standalone at localhost:9990 /] :shutdown(timeout=5)
> {"outcome" => "success"}
> {code}
> Provide access to this feature from an Arquillian test case  so that test cases may test with or without clean shutdown enabled.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:43:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when
 adding large deployment with audit logging enabled
In-Reply-To: <JIRA.12571787.1431651101000@Atlassian.JIRA>
References: <JIRA.12571787.1431651101000@Atlassian.JIRA>
	<JIRA.12571787.1431651101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571787.1431651101000.42454.1442518980263@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110197#comment-13110197 ] 

Brian Stansberry commented on WFCORE-695:
-----------------------------------------

Ah, good. I should have looked closer! Is there any CLI JIRA to improve that?

I'm reconsidering a bit doing nothing about this in the audit logging layer. Conceivably we could detect ModelType.BYTES and truncate the output if its too big. I don't think omitting it altogether is good; for example the 'hash' param for any deployment add op is ModelType.BYTES, and seeing what that value is is useful. Problem is there is no way to look the ModelNode's bytes in order to decide whether to manipulate like this except by calling node.asBytes() and that call results in a copy of the byte[].

> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-695
>                 URL: https://issues.jboss.org/browse/WFCORE-695
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 1.0.0.CR4
>            Reporter: James Livingston
>            Assignee: Alexey Loubyansky
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
>         at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
>         at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
>         at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 15:49:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 15:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4664) Enable Garbage Collection
 Logging by Default - missing feature from EAP6
In-Reply-To: <JIRA.12572553.1432537333000@Atlassian.JIRA>
References: <JIRA.12572553.1432537333000@Atlassian.JIRA>
	<JIRA.12572553.1432537333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572553.1432537333000.42475.1442519340304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-4664.
------------------------------------
    Fix Version/s:     (was: 10.0.0.CR2)
       Resolution: Rejected


Thanks for taking care of the JBEAP issue. This one isn't appropriate for WildFly. Jason can reopen if he disagrees.

> Enable Garbage Collection Logging by Default - missing feature from EAP6
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4664
>                 URL: https://issues.jboss.org/browse/WFLY-4664
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>            Priority: Optional
>
> Description of problem:
> GC logging java opts are not passed to standalone server
> Steps to Reproduce:
>  1. Start the standalone server (on windows or linux) and observe the console logs.
> Actual results:
> JAVA_OPTS: -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> Expected results:
> JAVA_OPTS:  -server -XX:+UseCompressedOops  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -verbose:gc -Xloggc:"$JBOSS_LOG_DIR/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading
> Additional info:
>    - EAP6 jira: https://issues.jboss.org/browse/EAP6-121
>    - EAP6-121 feature is commented in standalone.sh and standalone.bat
>    - these OPTS are missing: -verbose:gc -Xloggc:"$JBOSS_LOG_DIR/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 17 16:12:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Sep 2015 16:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1060) When starting JBoss AS -b
 should work no matter how I start JBoss AS to bind it to the local
 interface
In-Reply-To: <JIRA.12469850.1341334879000@Atlassian.JIRA>
References: <JIRA.12469850.1341334879000@Atlassian.JIRA>
	<JIRA.12469850.1341334879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469850.1341334879000.42500.1442520720110@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110208#comment-13110208 ] 

RH Bugzilla Integration commented on WFLY-1060:
-----------------------------------------------

anrobert at redhat.com changed the Status of [bug 1125025|https://bugzilla.redhat.com/show_bug.cgi?id=1125025] from ON_QA to MODIFIED

> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1060
>                 URL: https://issues.jboss.org/browse/WFLY-1060
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>              Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address.  Instead it binds to localhost 127.0.0.1.  It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 16:42:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 17 Sep 2015 16:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when
 adding large deployment with audit logging enabled
In-Reply-To: <JIRA.12571787.1431651101000@Atlassian.JIRA>
References: <JIRA.12571787.1431651101000@Atlassian.JIRA>
	<JIRA.12571787.1431651101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571787.1431651101000.42516.1442522520100@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110213#comment-13110213 ] 

Alexey Loubyansky commented on WFCORE-695:
------------------------------------------

There is no CLI Jira for that yet. I think I looked into supporting streams in cli batches at some point, which meant changing batch APIs and following decision to postpone. That would make sense though.

I think truncating would make sense for large values too as a guarding mechanism. Otherwise, if it's too big but has to be recorded in full, it would simply have to be logged/stored separately and referenced.
Or the log has to be fragmented. At least we could count the amount of data already written/logged. If it's critical then stop, persist, open another one and continue.

> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-695
>                 URL: https://issues.jboss.org/browse/WFCORE-695
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 1.0.0.CR4
>            Reporter: James Livingston
>            Assignee: Alexey Loubyansky
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
>         at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
>         at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
>         at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
>         at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
>         at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 16:53:00 2015
From: issues at jboss.org (David Weir (JIRA))
Date: Thu, 17 Sep 2015 16:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-920) DRL compiler throws NPE if
 you import a class from default package
In-Reply-To: <JIRA.12585300.1442523158000@Atlassian.JIRA>
References: <JIRA.12585300.1442523158000@Atlassian.JIRA>
	<JIRA.12585300.1442523158386@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585300.1442523158000.42528.1442523180135@Atlassian.JIRA>

David Weir created DROOLS-920:
---------------------------------

             Summary: DRL compiler throws NPE if you import a class from default package
                 Key: DROOLS-920
                 URL: https://issues.jboss.org/browse/DROOLS-920
             Project: Drools
          Issue Type: Bug
            Reporter: David Weir
            Assignee: Mark Proctor
         Attachments: DroolsLoopingTest.java, MyMessage.java

I am working on a looping problem and built the attached test case. It gives me this error when I run it:
Running DroolsLoopingTest
Creating new session 
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Exception in thread "main" java.lang.NullPointerException
	at org.drools.compiler.builder.impl.ClassHierarchyManager.inheritFields(ClassHierarchyManager.java:164)
	at org.drools.compiler.builder.impl.TypeDeclarationBuilder.createBean(TypeDeclarationBuilder.java:214)
	at org.drools.compiler.builder.impl.TypeDeclarationBuilder.processTypeDeclarations(TypeDeclarationBuilder.java:128)
	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildTypeDeclarations(CompositeKnowledgeBuilderImpl.java:274)
	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:116)
	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:104)
	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:238)
	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:64)
	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:225)
	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:196)
	at DroolsLoopingTest.createInMemoryKieSystem(DroolsLoopingTest.java:146)
	at DroolsLoopingTest.runTest(DroolsLoopingTest.java:106)
	at DroolsLoopingTest.main(DroolsLoopingTest.java:40)




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 16:56:00 2015
From: issues at jboss.org (David Weir (JIRA))
Date: Thu, 17 Sep 2015 16:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-921) Drools fires no rules with
 this Drools/CEP test
In-Reply-To: <JIRA.12585301.1442523320000@Atlassian.JIRA>
References: <JIRA.12585301.1442523320000@Atlassian.JIRA>
	<JIRA.12585301.1442523320438@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585301.1442523320000.42539.1442523360089@Atlassian.JIRA>

David Weir created DROOLS-921:
---------------------------------

             Summary: Drools fires no rules with this Drools/CEP test
                 Key: DROOLS-921
                 URL: https://issues.jboss.org/browse/DROOLS-921
             Project: Drools
          Issue Type: Bug
            Reporter: David Weir
            Assignee: Mark Proctor
         Attachments: DroolsLoopingTest.java, MyMessage.java

I'm debugging a looping test and when I run the attached, it fires no rules



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 16:58:00 2015
From: issues at jboss.org (David Weir (JIRA))
Date: Thu, 17 Sep 2015 16:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-922) Drools Loops with this CEP
	test
In-Reply-To: <JIRA.12585302.1442523468000@Atlassian.JIRA>
References: <JIRA.12585302.1442523468000@Atlassian.JIRA>
	<JIRA.12585302.1442523468640@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585302.1442523468000.42542.1442523480104@Atlassian.JIRA>

David Weir created DROOLS-922:
---------------------------------

             Summary: Drools Loops with this CEP test
                 Key: DROOLS-922
                 URL: https://issues.jboss.org/browse/DROOLS-922
             Project: Drools
          Issue Type: Bug
            Reporter: David Weir
            Assignee: Mark Proctor
         Attachments: DroolsLoopingTest.java, MyMessage.java

I want to emulate the workflow style rules using state guards. When I run the attached, it loops many times until the incoming event expires.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 17:23:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 17 Sep 2015 17:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923893@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.42561.1442524980102@Atlassian.JIRA>

James Perkins created WFCORE-988:
------------------------------------

             Summary: Host controller fails to roll out management operations if assertions are enabled
                 Key: WFCORE-988
                 URL: https://issues.jboss.org/browse/WFCORE-988
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: James Perkins
            Assignee: Brian Stansberry


Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].

Replacing the assertion with an exception I see the stack trace below.

{code:title=Stack Trace}
[Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
[Host Controller]     "address" => [
[Host Controller]         ("host" => "master"),
[Host Controller]         ("server" => "server-one"),
[Host Controller]         ("subsystem" => "logging")
[Host Controller]     ],
[Host Controller]     "operation" => "write-attribute",
[Host Controller]     "name" => "use-deployment-logging-config",
[Host Controller]     "value" => true,
[Host Controller]     "operation-headers" => {
[Host Controller]         "access-mechanism" => "NATIVE",
[Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
[Host Controller]         "execute-for-coordinator" => true
[Host Controller]     }
[Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
[Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
[Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
[Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
[Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
[Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
[Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
[Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
[Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
[Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
[Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
[Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
[Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
[Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
[Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Host Controller] 	at java.lang.Thread.run(Thread.java:745)
[Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 19:30:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 17 Sep 2015 19:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-104) Xnio Options passed in
 environment are not passed down
In-Reply-To: <JIRA.12585310.1442532560000@Atlassian.JIRA>
References: <JIRA.12585310.1442532560000@Atlassian.JIRA>
	<JIRA.12585310.1442532560963@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585310.1442532560000.42710.1442532600270@Atlassian.JIRA>

Brad Maxwell created REMJMX-104:
-----------------------------------

             Summary: Xnio Options passed in environment are not passed down
                 Key: REMJMX-104
                 URL: https://issues.jboss.org/browse/REMJMX-104
             Project: Remoting JMX
          Issue Type: Bug
          Components: Connection
    Affects Versions: 1.1.3.Final
            Reporter: Brad Maxwell
            Assignee: Darran Lofthouse


XNIO options are not passed down when specified in the environment, preventing the client from specifying things such as SSL_ENABLED=false
 
{code}
        JMXServiceURL jmxUrl = new JMXServiceURL(url);
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory");
        env.put("org.xnio.Options.SSL_ENABLED","false");
        String[] credentials = new String[] { user, pass }; 
        env.put(JMXConnector.CREDENTIALS, credentials);
        this.jmxConnector = JMXConnectorFactory.connect(jmxUrl, env);
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 19:31:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 17 Sep 2015 19:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-104) Xnio Options passed in
 environment are not passed down
In-Reply-To: <JIRA.12585310.1442532560000@Atlassian.JIRA>
References: <JIRA.12585310.1442532560000@Atlassian.JIRA>
	<JIRA.12585310.1442532560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585310.1442532560000.42713.1442532660137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated REMJMX-104:
--------------------------------
    Description: 
XNIO options are not passed down when specified in the environment, preventing the client from specifying things such as SSL_ENABLED=false
 
{code}
        JMXServiceURL jmxUrl = new JMXServiceURL(url);
        Hashtable env = new Hashtable();
        env.put("org.xnio.Options.SSL_ENABLED","false");
        String[] credentials = new String[] { user, pass }; 
        env.put(JMXConnector.CREDENTIALS, credentials);
        this.jmxConnector = JMXConnectorFactory.connect(jmxUrl, env);
{code}

  was:
XNIO options are not passed down when specified in the environment, preventing the client from specifying things such as SSL_ENABLED=false
 
{code}
        JMXServiceURL jmxUrl = new JMXServiceURL(url);
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory");
        env.put("org.xnio.Options.SSL_ENABLED","false");
        String[] credentials = new String[] { user, pass }; 
        env.put(JMXConnector.CREDENTIALS, credentials);
        this.jmxConnector = JMXConnectorFactory.connect(jmxUrl, env);
{code}



> Xnio Options passed in environment are not passed down
> ------------------------------------------------------
>
>                 Key: REMJMX-104
>                 URL: https://issues.jboss.org/browse/REMJMX-104
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>    Affects Versions: 1.1.3.Final
>            Reporter: Brad Maxwell
>            Assignee: Darran Lofthouse
>
> XNIO options are not passed down when specified in the environment, preventing the client from specifying things such as SSL_ENABLED=false
>  
> {code}
>         JMXServiceURL jmxUrl = new JMXServiceURL(url);
>         Hashtable env = new Hashtable();
>         env.put("org.xnio.Options.SSL_ENABLED","false");
>         String[] credentials = new String[] { user, pass }; 
>         env.put(JMXConnector.CREDENTIALS, credentials);
>         this.jmxConnector = JMXConnectorFactory.connect(jmxUrl, env);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 20:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 17 Sep 2015 20:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-845) The ActiveOperationSupport
 shouldn't use assertions for state as assertions can be turned off
In-Reply-To: <JIRA.12579666.1438109534000@Atlassian.JIRA>
References: <JIRA.12579666.1438109534000@Atlassian.JIRA>
	<JIRA.12579666.1438109534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579666.1438109534000.42745.1442536800300@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110249#comment-13110249 ] 

Brian Stansberry commented on WFCORE-845:
-----------------------------------------

The assertion discussed in WFCORE-845 needs to be disabled altogether until WFCORE-199 is fixed.

> The ActiveOperationSupport shouldn't use assertions for state as assertions can be turned off
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-845
>                 URL: https://issues.jboss.org/browse/WFCORE-845
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The [{{ActiveOperationSupport}}|https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/ActiveOperationSupport.java#L151] uses assertions to validate if the remote protocol has been shutdown. These should throw an exception rather than an {{AssertionError}} which can be turned off.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 20:47:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Thu, 17 Sep 2015 20:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197063@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.42750.1442537220181@Atlassian.JIRA>

Carlton Zachary created WFLY-5358:
-------------------------------------

             Summary: JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
                 Key: WFLY-5358
                 URL: https://issues.jboss.org/browse/WFLY-5358
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.CR1
            Reporter: Carlton Zachary
            Assignee: Paul Ferraro


WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead

WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 20:50:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Thu, 17 Sep 2015 20:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.42757.1442537400115@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlton Zachary updated WFLY-5358:
----------------------------------
    Description: 
I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead

WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored

JGroups configuration:
 <stacks default="tcp">
<stack name="tcp">
                        <transport type="TCP" socket-binding="jgroups-tcp"/>
                        <protocol type="TCPPING">
                            <property name="initial_hosts">
                                ${jboss.cluster.tcp.initial_hosts}
                            </property>
                            <property name="num_initial_members">
                                2
                            </property>
                            <property name="port_range">
                                0
                            </property>
                            <property name="timeout">
                                2000
                            </property>
                        </protocol>

  was:
WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead

WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored



> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 20:51:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Thu, 17 Sep 2015 20:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.42761.1442537460112@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlton Zachary updated WFLY-5358:
----------------------------------
    Description: 
I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.

WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead

WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored

JGroups configuration:
 <stacks default="tcp">
<stack name="tcp">
                        <transport type="TCP" socket-binding="jgroups-tcp"/>
                        <protocol type="TCPPING">
                            <property name="initial_hosts">
                                ${jboss.cluster.tcp.initial_hosts}
                            </property>
                            <property name="num_initial_members">
                                2
                            </property>
                            <property name="port_range">
                                0
                            </property>
                            <property name="timeout">
                                2000
                            </property>
                        </protocol>

  was:
I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead

WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored

JGroups configuration:
 <stacks default="tcp">
<stack name="tcp">
                        <transport type="TCP" socket-binding="jgroups-tcp"/>
                        <protocol type="TCPPING">
                            <property name="initial_hosts">
                                ${jboss.cluster.tcp.initial_hosts}
                            </property>
                            <property name="num_initial_members">
                                2
                            </property>
                            <property name="port_range">
                                0
                            </property>
                            <property name="timeout">
                                2000
                            </property>
                        </protocol>



> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 21:04:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 17 Sep 2015 21:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.42785.1442538240519@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-5358.
------------------------------
    Resolution: Rejected


This is not a bug.  These deprecation warning should be addressed by fixing your jgroups subsystem configuration.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 23:40:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 17 Sep 2015 23:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4827) Network Connection leak on
 client abort connection
In-Reply-To: <JIRA.12576157.1435155599000@Atlassian.JIRA>
References: <JIRA.12576157.1435155599000@Atlassian.JIRA>
	<JIRA.12576157.1435155599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576157.1435155599000.43390.1442547600278@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110261#comment-13110261 ] 

Stuart Douglas commented on WFLY-4827:
--------------------------------------

I don't know why I did not think about this before but this could be a TCP configuration issue with your system. If the client just drops out entirely and you do not have TCP keepalive it can be a long time before the socket times out (there is nothing that can be done in this case other than time out, as there is no way to tell the difference between the client loosing connectivity vs the client just taking a while to sent).

I think your only real option here is to configure some appropriate timeouts, either the Undertow read timeout, or at a TCP level.




> Network Connection leak on client abort connection
> --------------------------------------------------
>
>                 Key: WFLY-4827
>                 URL: https://issues.jboss.org/browse/WFLY-4827
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow), Web Sockets
>    Affects Versions: 8.2.0.Final
>         Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
>            Reporter: Andrea Bertolini
>            Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored. 
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.  
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call. 
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response. 
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore). 
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze. 
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 17 23:40:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 17 Sep 2015 23:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4827) Network Connection leak on
 client abort connection
In-Reply-To: <JIRA.12576157.1435155599000@Atlassian.JIRA>
References: <JIRA.12576157.1435155599000@Atlassian.JIRA>
	<JIRA.12576157.1435155599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576157.1435155599000.43393.1442547600329@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-4827.
----------------------------------
    Resolution: Rejected


> Network Connection leak on client abort connection
> --------------------------------------------------
>
>                 Key: WFLY-4827
>                 URL: https://issues.jboss.org/browse/WFLY-4827
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow), Web Sockets
>    Affects Versions: 8.2.0.Final
>         Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
>            Reporter: Andrea Bertolini
>            Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored. 
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.  
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call. 
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response. 
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore). 
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze. 
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 02:39:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 02:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5359) [Migration operation] [Web to
 Undertow] Incorectly printed warning for unable to migrate resource in case
 of migrating ssl configuration
In-Reply-To: <JIRA.12585320.1442558311000@Atlassian.JIRA>
References: <JIRA.12585320.1442558311000@Atlassian.JIRA>
	<JIRA.12585320.1442558311835@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585320.1442558311000.43519.1442558340672@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5359:
--------------------------------------

             Summary: [Migration operation] [Web to Undertow] Incorectly printed warning for unable to migrate resource in case of migrating ssl configuration
                 Key: WFLY-5359
                 URL: https://issues.jboss.org/browse/WFLY-5359
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas


When migrating https connector with SSL configuration, the SSL configuration is migrated as part of the https connector migration. Still there is migration warning that {{:migrate}} operation isn't able to migrate the ssl configuration even though it was successfully migrated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 02:39:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 02:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5359) [Migration operation] [Web to
 Undertow] Incorectly printed warning for unable to migrate resource in case
 of migrating ssl configuration
In-Reply-To: <JIRA.12585320.1442558311000@Atlassian.JIRA>
References: <JIRA.12585320.1442558311000@Atlassian.JIRA>
	<JIRA.12585320.1442558311000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585320.1442558311000.43522.1442558340803@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka reassigned WFLY-5359:
--------------------------------------

    Assignee: Radim Hatlapatka  (was: Stuart Douglas)


> [Migration operation] [Web to Undertow] Incorectly printed warning for unable to migrate resource in case of migrating ssl configuration
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5359
>                 URL: https://issues.jboss.org/browse/WFLY-5359
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Radim Hatlapatka
>
> When migrating https connector with SSL configuration, the SSL configuration is migrated as part of the https connector migration. Still there is migration warning that {{:migrate}} operation isn't able to migrate the ssl configuration even though it was successfully migrated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:00:01 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 18 Sep 2015 04:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3659) wildfly 8 digest login-config
 throws javax.security.auth.callback.UnsupportedCallbackException
In-Reply-To: <JIRA.12547249.1406113915000@Atlassian.JIRA>
References: <JIRA.12547249.1406113915000@Atlassian.JIRA>
	<JIRA.12547249.1406113915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547249.1406113915000.43714.1442563201433@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-3659:
------------------------------
    Description: 
Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.

{code:xml|title=web.xml|borderStyle=solid}
<security-role>
      <role-name>administrator</role-name>
</security-role>
{code}

<login-config>
      <auth-method>DIGEST</auth-method>
      <realm-name>WildFly8DigestRealm</realm-name>
</login-config>

== jboss-web.xml
<jboss-web>
    <security-domain>java:/jaas/my_secure_domain</security-domain>
</jboss-web>

== standalone.xml
<security-domain name="my_secure_domain" cache-type="default">
     <authentication>
          <login-module code="Database" flag="required">
               <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
               <module-option name="principalsQuery" value="select password from credential where uid=?"/>
               <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
               <module-option name="hashAlgorithm" value="MD5"/>
               <module-option name="hashEncoding" value="RFC2617"/>
               <module-option name="hashUserPassword" value="false"/>
               <module-option name="hashStorePassword" value="true"/>
               <module-option name="passwordIsA1Hash" value="true"/>
               <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
               <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
          </login-module>
     </authentication>
</security-domain>

Password is encrypted with below codes
== EncryptPassword.java
package com.aaa.encrypt;

import org.jboss.crypto.CryptoUtil;

public class EncryptPassword {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        String userName="admin"; 
        String realmName="WildFly8DigestRealm"; 
        String password="passwd123"; 

        String clearTextPassword=userName+":"+realmName+":"+password;  
        String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
        System.out.println("clearTextPassword: "+clearTextPassword); 
        System.out.println("hashedPassword: "+hashedPassword); 
    }
}

But login failed! The log shows the folowing exceptions :
2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
 at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
 at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]

Caused by: javax.security.auth.callback.UnsupportedCallbackException
 at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 ... 49 more

This cofiguration worked well in JBoss AS 7.

  was:
Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.

== web.xml
<security-role>
      <role-name>administrator</role-name>
</security-role>

<login-config>
      <auth-method>DIGEST</auth-method>
      <realm-name>WildFly8DigestRealm</realm-name>
</login-config>

== jboss-web.xml
<jboss-web>
    <security-domain>java:/jaas/my_secure_domain</security-domain>
</jboss-web>

== standalone.xml
<security-domain name="my_secure_domain" cache-type="default">
     <authentication>
          <login-module code="Database" flag="required">
               <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
               <module-option name="principalsQuery" value="select password from credential where uid=?"/>
               <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
               <module-option name="hashAlgorithm" value="MD5"/>
               <module-option name="hashEncoding" value="RFC2617"/>
               <module-option name="hashUserPassword" value="false"/>
               <module-option name="hashStorePassword" value="true"/>
               <module-option name="passwordIsA1Hash" value="true"/>
               <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
               <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
          </login-module>
     </authentication>
</security-domain>

Password is encrypted with below codes
== EncryptPassword.java
package com.aaa.encrypt;

import org.jboss.crypto.CryptoUtil;

public class EncryptPassword {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        String userName="admin"; 
        String realmName="WildFly8DigestRealm"; 
        String password="passwd123"; 

        String clearTextPassword=userName+":"+realmName+":"+password;  
        String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
        System.out.println("clearTextPassword: "+clearTextPassword); 
        System.out.println("hashedPassword: "+hashedPassword); 
    }
}

But login failed! The log shows the folowing exceptions :
2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
 at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
 at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]

Caused by: javax.security.auth.callback.UnsupportedCallbackException
 at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 ... 49 more

This cofiguration worked well in JBoss AS 7.



> wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3659
>                 URL: https://issues.jboss.org/browse/WFLY-3659
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.1.0.Final
>            Reporter: Joseph Hwang
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.
> {code:xml|title=web.xml|borderStyle=solid}
> <security-role>
>       <role-name>administrator</role-name>
> </security-role>
> {code}
> <login-config>
>       <auth-method>DIGEST</auth-method>
>       <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> == jboss-web.xml
> <jboss-web>
>     <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> == standalone.xml
> <security-domain name="my_secure_domain" cache-type="default">
>      <authentication>
>           <login-module code="Database" flag="required">
>                <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
>                <module-option name="principalsQuery" value="select password from credential where uid=?"/>
>                <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
>                <module-option name="hashAlgorithm" value="MD5"/>
>                <module-option name="hashEncoding" value="RFC2617"/>
>                <module-option name="hashUserPassword" value="false"/>
>                <module-option name="hashStorePassword" value="true"/>
>                <module-option name="passwordIsA1Hash" value="true"/>
>                <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
>                <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
>           </login-module>
>      </authentication>
> </security-domain>
> Password is encrypted with below codes
> == EncryptPassword.java
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
>     public static void main(String[] args) {
>         // TODO Auto-generated method stub
>         String userName="admin"; 
>         String realmName="WildFly8DigestRealm"; 
>         String password="passwd123"; 
>         String clearTextPassword=userName+":"+realmName+":"+password;  
>         String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
>         System.out.println("clearTextPassword: "+clearTextPassword); 
>         System.out.println("hashedPassword: "+hashedPassword); 
>     }
> }
> But login failed! The log shows the folowing exceptions :
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
>  at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  ... 49 more
> This cofiguration worked well in JBoss AS 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:18:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 04:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5360) [Migration operation] [Web to
 Undertow] Migrating https connector in domain fails
In-Reply-To: <JIRA.12585329.1442564248000@Atlassian.JIRA>
References: <JIRA.12585329.1442564248000@Atlassian.JIRA>
	<JIRA.12585329.1442564248313@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585329.1442564248000.43768.1442564280188@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5360:
--------------------------------------

             Summary: [Migration operation] [Web to Undertow] Migrating https connector in domain fails
                 Key: WFLY-5360
                 URL: https://issues.jboss.org/browse/WFLY-5360
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Critical


When trying to migrate https connector in domain, it fails during creation of security realm, as the operation assumes that security realms are set in domain also under {{/core-service=management/}} but they are set specifically for host => in case of host master it is {{/host=master/core-service=management/}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:18:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 04:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5360) [Migration operation] [Web to
 Undertow] Migrating https connector in domain fails
In-Reply-To: <JIRA.12585329.1442564248000@Atlassian.JIRA>
References: <JIRA.12585329.1442564248000@Atlassian.JIRA>
	<JIRA.12585329.1442564248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585329.1442564248000.43771.1442564280282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-5360:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> [Migration operation] [Web to Undertow] Migrating https connector in domain fails
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5360
>                 URL: https://issues.jboss.org/browse/WFLY-5360
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> When trying to migrate https connector in domain, it fails during creation of security realm, as the operation assumes that security realms are set in domain also under {{/core-service=management/}} but they are set specifically for host => in case of host master it is {{/host=master/core-service=management/}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:18:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 04:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5359) [Migration operation] [Web to
 Undertow] Incorectly printed warning for unable to migrate resource in case
 of migrating ssl configuration
In-Reply-To: <JIRA.12585320.1442558311000@Atlassian.JIRA>
References: <JIRA.12585320.1442558311000@Atlassian.JIRA>
	<JIRA.12585320.1442558311000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585320.1442558311000.43773.1442564280397@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-5359:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> [Migration operation] [Web to Undertow] Incorectly printed warning for unable to migrate resource in case of migrating ssl configuration
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5359
>                 URL: https://issues.jboss.org/browse/WFLY-5359
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radim Hatlapatka
>            Assignee: Radim Hatlapatka
>
> When migrating https connector with SSL configuration, the SSL configuration is migrated as part of the https connector migration. Still there is migration warning that {{:migrate}} operation isn't able to migrate the ssl configuration even though it was successfully migrated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:32:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 18 Sep 2015 04:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-923) KieRepository is not thread
	safe
In-Reply-To: <JIRA.12585332.1442565116000@Atlassian.JIRA>
References: <JIRA.12585332.1442565116000@Atlassian.JIRA>
	<JIRA.12585332.1442565116466@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585332.1442565116000.43831.1442565120137@Atlassian.JIRA>

Mario Fusco created DROOLS-923:
----------------------------------

             Summary: KieRepository is not thread safe
                 Key: DROOLS-923
                 URL: https://issues.jboss.org/browse/DROOLS-923
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


KieRepository is not thread safe so concurrently adding and removing KieModules could lead to a NPE.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:42:00 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 18 Sep 2015 04:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3659) wildfly 8 digest login-config
 throws javax.security.auth.callback.UnsupportedCallbackException
In-Reply-To: <JIRA.12547249.1406113915000@Atlassian.JIRA>
References: <JIRA.12547249.1406113915000@Atlassian.JIRA>
	<JIRA.12547249.1406113915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547249.1406113915000.43853.1442565720336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reopened WFLY-3659:
-------------------------------


Reopened, Elytron is not included in WildFly 10.

> wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3659
>                 URL: https://issues.jboss.org/browse/WFLY-3659
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.1.0.Final
>            Reporter: Joseph Hwang
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.
> {code:xml|title=web.xml|borderStyle=solid}
> <security-role>
>       <role-name>administrator</role-name>
> </security-role>
> {code}
> <login-config>
>       <auth-method>DIGEST</auth-method>
>       <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> == jboss-web.xml
> <jboss-web>
>     <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> == standalone.xml
> <security-domain name="my_secure_domain" cache-type="default">
>      <authentication>
>           <login-module code="Database" flag="required">
>                <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
>                <module-option name="principalsQuery" value="select password from credential where uid=?"/>
>                <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
>                <module-option name="hashAlgorithm" value="MD5"/>
>                <module-option name="hashEncoding" value="RFC2617"/>
>                <module-option name="hashUserPassword" value="false"/>
>                <module-option name="hashStorePassword" value="true"/>
>                <module-option name="passwordIsA1Hash" value="true"/>
>                <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
>                <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
>           </login-module>
>      </authentication>
> </security-domain>
> Password is encrypted with below codes
> == EncryptPassword.java
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
>     public static void main(String[] args) {
>         // TODO Auto-generated method stub
>         String userName="admin"; 
>         String realmName="WildFly8DigestRealm"; 
>         String password="passwd123"; 
>         String clearTextPassword=userName+":"+realmName+":"+password;  
>         String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
>         System.out.println("clearTextPassword: "+clearTextPassword); 
>         System.out.println("hashedPassword: "+hashedPassword); 
>     }
> }
> But login failed! The log shows the folowing exceptions :
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
>  at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  ... 49 more
> This cofiguration worked well in JBoss AS 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:44:00 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 18 Sep 2015 04:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3659) wildfly 8 digest login-config
 throws javax.security.auth.callback.UnsupportedCallbackException
In-Reply-To: <JIRA.12547249.1406113915000@Atlassian.JIRA>
References: <JIRA.12547249.1406113915000@Atlassian.JIRA>
	<JIRA.12547249.1406113915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547249.1406113915000.43867.1442565840552@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-3659:
------------------------------
          Description: 
Password encryption in database login module with wildfly digest login config throws {{javax.security.auth.callback.UnsupportedCallbackException}}. These are sources.

{code:xml|title=web.xml|borderStyle=solid}
<security-role>
      <role-name>administrator</role-name>
</security-role>

<login-config>
      <auth-method>DIGEST</auth-method>
      <realm-name>WildFly8DigestRealm</realm-name>
</login-config>
{code}

{code:xml|title=jboss-web.xml|borderStyle=solid}
<jboss-web>
    <security-domain>java:/jaas/my_secure_domain</security-domain>
</jboss-web>
{code}

{code:xml|title=standalone.xml|borderStyle=solid}
<security-domain name="my_secure_domain" cache-type="default">
     <authentication>
          <login-module code="Database" flag="required">
               <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
               <module-option name="principalsQuery" value="select password from credential where uid=?"/>
               <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
               <module-option name="hashAlgorithm" value="MD5"/>
               <module-option name="hashEncoding" value="RFC2617"/>
               <module-option name="hashUserPassword" value="false"/>
               <module-option name="hashStorePassword" value="true"/>
               <module-option name="passwordIsA1Hash" value="true"/>
               <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
               <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
          </login-module>
     </authentication>
</security-domain>
{code}

Password is encrypted with below codes

{code:java|title=EncryptPassword.java|borderStyle=solid}
package com.aaa.encrypt;

import org.jboss.crypto.CryptoUtil;

public class EncryptPassword {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        String userName="admin"; 
        String realmName="WildFly8DigestRealm"; 
        String password="passwd123"; 

        String clearTextPassword=userName+":"+realmName+":"+password;  
        String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
        System.out.println("clearTextPassword: "+clearTextPassword); 
        System.out.println("hashedPassword: "+hashedPassword); 
    }
}
{code}

But login failed! The log shows the folowing exceptions :
{code}
2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
 at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
 at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]

Caused by: javax.security.auth.callback.UnsupportedCallbackException
 at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 ... 49 more
{code}

This cofiguration worked well in JBoss AS 7.

  was:
Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.

{code:xml|title=web.xml|borderStyle=solid}
<security-role>
      <role-name>administrator</role-name>
</security-role>
{code}

<login-config>
      <auth-method>DIGEST</auth-method>
      <realm-name>WildFly8DigestRealm</realm-name>
</login-config>

== jboss-web.xml
<jboss-web>
    <security-domain>java:/jaas/my_secure_domain</security-domain>
</jboss-web>

== standalone.xml
<security-domain name="my_secure_domain" cache-type="default">
     <authentication>
          <login-module code="Database" flag="required">
               <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
               <module-option name="principalsQuery" value="select password from credential where uid=?"/>
               <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
               <module-option name="hashAlgorithm" value="MD5"/>
               <module-option name="hashEncoding" value="RFC2617"/>
               <module-option name="hashUserPassword" value="false"/>
               <module-option name="hashStorePassword" value="true"/>
               <module-option name="passwordIsA1Hash" value="true"/>
               <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
               <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
          </login-module>
     </authentication>
</security-domain>

Password is encrypted with below codes
== EncryptPassword.java
package com.aaa.encrypt;

import org.jboss.crypto.CryptoUtil;

public class EncryptPassword {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        String userName="admin"; 
        String realmName="WildFly8DigestRealm"; 
        String password="passwd123"; 

        String clearTextPassword=userName+":"+realmName+":"+password;  
        String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
        System.out.println("clearTextPassword: "+clearTextPassword); 
        System.out.println("hashedPassword: "+hashedPassword); 
    }
}

But login failed! The log shows the folowing exceptions :
2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
 at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
 at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
 at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
 at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]

Caused by: javax.security.auth.callback.UnsupportedCallbackException
 at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
 at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
 at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
 ... 49 more

This cofiguration worked well in JBoss AS 7.

        Fix Version/s:     (was: 9.0.0.CR1)
             Priority: Blocker  (was: Major)
    Affects Version/s: 10.0.0.CR1
                       9.0.1.Final


Priority increased, description formatting added.

> wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3659
>                 URL: https://issues.jboss.org/browse/WFLY-3659
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.1.0.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Joseph Hwang
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> Password encryption in database login module with wildfly digest login config throws {{javax.security.auth.callback.UnsupportedCallbackException}}. These are sources.
> {code:xml|title=web.xml|borderStyle=solid}
> <security-role>
>       <role-name>administrator</role-name>
> </security-role>
> <login-config>
>       <auth-method>DIGEST</auth-method>
>       <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> {code}
> {code:xml|title=jboss-web.xml|borderStyle=solid}
> <jboss-web>
>     <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> {code}
> {code:xml|title=standalone.xml|borderStyle=solid}
> <security-domain name="my_secure_domain" cache-type="default">
>      <authentication>
>           <login-module code="Database" flag="required">
>                <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
>                <module-option name="principalsQuery" value="select password from credential where uid=?"/>
>                <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
>                <module-option name="hashAlgorithm" value="MD5"/>
>                <module-option name="hashEncoding" value="RFC2617"/>
>                <module-option name="hashUserPassword" value="false"/>
>                <module-option name="hashStorePassword" value="true"/>
>                <module-option name="passwordIsA1Hash" value="true"/>
>                <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
>                <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
>           </login-module>
>      </authentication>
> </security-domain>
> {code}
> Password is encrypted with below codes
> {code:java|title=EncryptPassword.java|borderStyle=solid}
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
>     public static void main(String[] args) {
>         // TODO Auto-generated method stub
>         String userName="admin"; 
>         String realmName="WildFly8DigestRealm"; 
>         String password="passwd123"; 
>         String clearTextPassword=userName+":"+realmName+":"+password;  
>         String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
>         System.out.println("clearTextPassword: "+clearTextPassword); 
>         System.out.println("hashedPassword: "+hashedPassword); 
>     }
> }
> {code}
> But login failed! The log shows the folowing exceptions :
> {code}
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
>  at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  ... 49 more
> {code}
> This cofiguration worked well in JBoss AS 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:45:01 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 18 Sep 2015 04:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3659) DIGEST authentication method
 throws javax.security.auth.callback.UnsupportedCallbackException
In-Reply-To: <JIRA.12547249.1406113915000@Atlassian.JIRA>
References: <JIRA.12547249.1406113915000@Atlassian.JIRA>
	<JIRA.12547249.1406113915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547249.1406113915000.43873.1442565901104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-3659:
------------------------------
    Summary: DIGEST authentication method throws javax.security.auth.callback.UnsupportedCallbackException  (was: wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException)


> DIGEST authentication method throws javax.security.auth.callback.UnsupportedCallbackException
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3659
>                 URL: https://issues.jboss.org/browse/WFLY-3659
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.1.0.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Joseph Hwang
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> Password encryption in database login module with wildfly digest login config throws {{javax.security.auth.callback.UnsupportedCallbackException}}. These are sources.
> {code:xml|title=web.xml|borderStyle=solid}
> <security-role>
>       <role-name>administrator</role-name>
> </security-role>
> <login-config>
>       <auth-method>DIGEST</auth-method>
>       <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> {code}
> {code:xml|title=jboss-web.xml|borderStyle=solid}
> <jboss-web>
>     <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> {code}
> {code:xml|title=standalone.xml|borderStyle=solid}
> <security-domain name="my_secure_domain" cache-type="default">
>      <authentication>
>           <login-module code="Database" flag="required">
>                <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
>                <module-option name="principalsQuery" value="select password from credential where uid=?"/>
>                <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
>                <module-option name="hashAlgorithm" value="MD5"/>
>                <module-option name="hashEncoding" value="RFC2617"/>
>                <module-option name="hashUserPassword" value="false"/>
>                <module-option name="hashStorePassword" value="true"/>
>                <module-option name="passwordIsA1Hash" value="true"/>
>                <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
>                <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
>           </login-module>
>      </authentication>
> </security-domain>
> {code}
> Password is encrypted with below codes
> {code:java|title=EncryptPassword.java|borderStyle=solid}
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
>     public static void main(String[] args) {
>         // TODO Auto-generated method stub
>         String userName="admin"; 
>         String realmName="WildFly8DigestRealm"; 
>         String password="passwd123"; 
>         String clearTextPassword=userName+":"+realmName+":"+password;  
>         String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
>         System.out.println("clearTextPassword: "+clearTextPassword); 
>         System.out.println("hashedPassword: "+hashedPassword); 
>     }
> }
> {code}
> But login failed! The log shows the folowing exceptions :
> {code}
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
>  at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  ... 49 more
> {code}
> This cofiguration worked well in JBoss AS 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 04:46:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 18 Sep 2015 04:46:00 -0400 (EDT)
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.43885.1442565960585@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-4975.
-------------------------------
    Fix Version/s: 10.0.0.CR1
       Resolution: Done


Artemis 1.1.0-wildfly-6 release with the underlying issue has been integrated in WFLY-5342

> 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
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 04:47:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 18 Sep 2015 04:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-923) KieRepository is not thread
	safe
In-Reply-To: <JIRA.12585332.1442565116000@Atlassian.JIRA>
References: <JIRA.12585332.1442565116000@Atlassian.JIRA>
	<JIRA.12585332.1442565116000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585332.1442565116000.43887.1442566020065@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-923.
--------------------------------
    Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/187ef04d6

> KieRepository is not thread safe
> --------------------------------
>
>                 Key: DROOLS-923
>                 URL: https://issues.jboss.org/browse/DROOLS-923
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> KieRepository is not thread safe so concurrently adding and removing KieModules could lead to a NPE.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 05:04:00 2015
From: issues at jboss.org (Erich Duda (JIRA))
Date: Fri, 18 Sep 2015 05:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5361) Reload operation causes crash
 of EAP server
In-Reply-To: <JIRA.12585338.1442567011000@Atlassian.JIRA>
References: <JIRA.12585338.1442567011000@Atlassian.JIRA>
	<JIRA.12585338.1442567011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585338.1442567011000.43929.1442567040929@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda moved JBEAP-1104 to WFLY-5361:
-----------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5361  (was: JBEAP-1104)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: CLI
                           (was: CLI)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR9)


> Reload operation causes crash of EAP server
> -------------------------------------------
>
>                 Key: WFLY-5361
>                 URL: https://issues.jboss.org/browse/WFLY-5361
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 10.0.0.CR1
>         Environment: Fedora 22, RHEL 7 ++ OpenJDK 8 - crash of EAP server
> Fedora 22, RHEL 7 ++ IBM Java 1.8 - crash of JVM where runs the EAP server
> {panel}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {panel}
>            Reporter: Erich Duda
>            Assignee: Alexey Loubyansky
>         Attachments: javacore.20150917.161241.19157.0002.txt, server-openjdk.log, Snap.20150917.161241.19157.0003.trc
>
>
> Repeated execution of reload request causes EAP server crash.
> {panel}
> 10:43:15,179 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1 at 3d119a3c" failed: java.lang.IllegalArgumentException: Container is shutting down
>         at org.jboss.msc.service.ServiceControllerImpl.internalSetMode(ServiceControllerImpl.java:762) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.setMode(ServiceControllerImpl.java:753) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.transition(ProcessReloadHandler.java:90) [wildfly-controller-2.0.0.Beta4.jar:2.0.0.Beta4]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [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_60]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {panel}
> On IBM Java reload resquests cause even JVM crash.
> {panel}
> #0: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x8a455f) [0x7f44cce6055f]
> #1: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1042f1) [0x7f44cc6c02f1]
> #2: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x255ee) [0x7f44d8b515ee]
> #3: /lib64/libpthread.so.0(+0x10430) [0x7f44dafd9430]
> #4: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x74909e) [0x7f44ccd0509e]
> #5: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x749372) [0x7f44ccd05372]
> #6: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x437922) [0x7f44cc9f3922]
> #7: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x4385bb) [0x7f44cc9f45bb]
> #8: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x448e10) [0x7f44cca04e10]
> #9: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x449855) [0x7f44cca05855]
> #10: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dd5d) [0x7f44cca09d5d]
> #11: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #12: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #13: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #14: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #15: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #16: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44ec75) [0x7f44cca0ac75]
> #17: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44effb) [0x7f44cca0affb]
> #18: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cd94d) [0x7f44cc88994d]
> #19: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cdc19) [0x7f44cc889c19]
> #20: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cee94) [0x7f44cc88ae94]
> #21: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7c748b) [0x7f44ccd8348b]
> #22: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7cee4c) [0x7f44ccd8ae4c]
> #23: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10c7b5) [0x7f44cc6c87b5]
> #24: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10dcab) [0x7f44cc6c9cab]
> #25: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #26: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10fdf0) [0x7f44cc6cbdf0]
> #27: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1110ed) [0x7f44cc6cd0ed]
> #28: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #29: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x111a04) [0x7f44cc6cda04]
> Unhandled exception
> Type=Segmentation error vmState=0x00051cff
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F44D920CD90 Handler2=00007F44D8B513F0 InaccessibleAddress=0000000000000000
> RDI=00007F440613D710 RSI=FFFFFFFFFFDF3B65 RAX=0000000000000000 RBX=00007F4406141390
> RCX=0000000000000026 RDX=0000000000000001 R8=00007F44CCF4EA52 R9=0000000000000000
> R10=00007F4406145740 R11=0000000000000003 R12=00007F44076AEF00 R13=0000000000000000
> R14=0000000000000000 R15=0000000000000000
> RIP=00007F44CCD0509E GS=0000 FS=0000 RSP=00007F44C9A84C20
> EFlags=0000000000210246 CS=0033 RBP=0000000000000000 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f44003b6e6f (f: 3894895,000000, d: 6,913462e-310)
> xmm1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm2 616c2f6176616a4c (f: 1986095744,000000, d: 1,981285e+161)
> xmm3 6a00656c62617468 (f: 1650553984,000000, d: 4,016150e+202)
> xmm4 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm5 03d303d203d103d0 (f: 64029648,000000, d: 3,048729e-290)
> xmm6 49676e697274532f (f: 1920226048,000000, d: 4,180283e+45)
> xmm7 4573646e756f4266 (f: 1970225792,000000, d: 3,751018e+26)
> xmm8 03d603d503d403d3 (f: 64226260,000000, d: 3,529736e-290)
> xmm9 03de03dd03dc03db (f: 64750556,000000, d: 4,812424e-290)
> xmm10 03e603e503e403e3 (f: 65274852,000000, d: 7,059551e-290)
> xmm11 03ee03ed03ec03eb (f: 65799148,000000, d: 9,624926e-290)
> xmm12 03f603f503f403f3 (f: 66323444,000000, d: 1,411926e-289)
> xmm13 03fe03fd03fc03fb (f: 66847740,000000, d: 1,925001e-289)
> xmm14 0406040504040403 (f: 67372032,000000, d: 2,823883e-289)
> xmm15 040e040d040c040b (f: 67896328,000000, d: 3,850033e-289)
> Module=/opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so
> Module_base_address=00007F44CC5BC000
> Method_being_compiled=org/jboss/as/controller/OperationContextImpl$ContextServiceBuilder.install()Lorg/jboss/msc/service/ServiceController;
> Target=2_80_20150630_255633 (Linux 4.1.6-201.fc22.x86_64)
> CPU=amd64 (8 logical CPUs) (0x3d3def000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F44CCD0509E [libj9jit28.so+0x74909e])
> (0x00007F44CCD05372 [libj9jit28.so+0x749372])
> (0x00007F44CC9F3922 [libj9jit28.so+0x437922])
> (0x00007F44CC9F45BB [libj9jit28.so+0x4385bb])
> (0x00007F44CCA04E10 [libj9jit28.so+0x448e10])
> (0x00007F44CCA05855 [libj9jit28.so+0x449855])
> (0x00007F44CCA09D5D [libj9jit28.so+0x44dd5d])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA0AC75 [libj9jit28.so+0x44ec75])
> (0x00007F44CCA0AFFB [libj9jit28.so+0x44effb])
> (0x00007F44CC88994D [libj9jit28.so+0x2cd94d])
> (0x00007F44CC889C19 [libj9jit28.so+0x2cdc19])
> (0x00007F44CC88AE94 [libj9jit28.so+0x2cee94])
> (0x00007F44CCD8348B [libj9jit28.so+0x7c748b])
> (0x00007F44CCD8AE4C [libj9jit28.so+0x7cee4c])
> (0x00007F44CC6C87B5 [libj9jit28.so+0x10c7b5])
> (0x00007F44CC6C9CAB [libj9jit28.so+0x10dcab])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CBDF0 [libj9jit28.so+0x10fdf0])
> (0x00007F44CC6CD0ED [libj9jit28.so+0x1110ed])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CDA04 [libj9jit28.so+0x111a04])
> (0x00007F44D8F8E9EC [libj9thr28.so+0x99ec])
> (0x00007F44DAFD0555 [libpthread.so.0+0x7555])
> clone+0x6d (0x00007F44DA8F0B9D [libc.so.6+0x102b9d])
> {panel}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 05:06:00 2015
From: issues at jboss.org (Erich Duda (JIRA))
Date: Fri, 18 Sep 2015 05:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5361) Reload operation causes crash
 of EAP server
In-Reply-To: <JIRA.12585338.1442567011000@Atlassian.JIRA>
References: <JIRA.12585338.1442567011000@Atlassian.JIRA>
	<JIRA.12585338.1442567011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585338.1442567011000.43941.1442567160642@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFLY-5361:
-----------------------------
    Component/s: Domain Management
                     (was: CLI)


> Reload operation causes crash of EAP server
> -------------------------------------------
>
>                 Key: WFLY-5361
>                 URL: https://issues.jboss.org/browse/WFLY-5361
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.0.0.CR1
>         Environment: Fedora 22, RHEL 7 ++ OpenJDK 8 - crash of EAP server
> Fedora 22, RHEL 7 ++ IBM Java 1.8 - crash of JVM where runs the EAP server
> {panel}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {panel}
>            Reporter: Erich Duda
>            Assignee: Alexey Loubyansky
>         Attachments: javacore.20150917.161241.19157.0002.txt, server-openjdk.log, Snap.20150917.161241.19157.0003.trc
>
>
> Repeated execution of reload request causes EAP server crash.
> {panel}
> 10:43:15,179 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1 at 3d119a3c" failed: java.lang.IllegalArgumentException: Container is shutting down
>         at org.jboss.msc.service.ServiceControllerImpl.internalSetMode(ServiceControllerImpl.java:762) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.setMode(ServiceControllerImpl.java:753) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.transition(ProcessReloadHandler.java:90) [wildfly-controller-2.0.0.Beta4.jar:2.0.0.Beta4]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [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_60]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {panel}
> On IBM Java reload resquests cause even JVM crash.
> {panel}
> #0: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x8a455f) [0x7f44cce6055f]
> #1: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1042f1) [0x7f44cc6c02f1]
> #2: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x255ee) [0x7f44d8b515ee]
> #3: /lib64/libpthread.so.0(+0x10430) [0x7f44dafd9430]
> #4: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x74909e) [0x7f44ccd0509e]
> #5: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x749372) [0x7f44ccd05372]
> #6: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x437922) [0x7f44cc9f3922]
> #7: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x4385bb) [0x7f44cc9f45bb]
> #8: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x448e10) [0x7f44cca04e10]
> #9: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x449855) [0x7f44cca05855]
> #10: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dd5d) [0x7f44cca09d5d]
> #11: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #12: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #13: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #14: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #15: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #16: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44ec75) [0x7f44cca0ac75]
> #17: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44effb) [0x7f44cca0affb]
> #18: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cd94d) [0x7f44cc88994d]
> #19: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cdc19) [0x7f44cc889c19]
> #20: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cee94) [0x7f44cc88ae94]
> #21: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7c748b) [0x7f44ccd8348b]
> #22: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7cee4c) [0x7f44ccd8ae4c]
> #23: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10c7b5) [0x7f44cc6c87b5]
> #24: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10dcab) [0x7f44cc6c9cab]
> #25: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #26: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10fdf0) [0x7f44cc6cbdf0]
> #27: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1110ed) [0x7f44cc6cd0ed]
> #28: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #29: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x111a04) [0x7f44cc6cda04]
> Unhandled exception
> Type=Segmentation error vmState=0x00051cff
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F44D920CD90 Handler2=00007F44D8B513F0 InaccessibleAddress=0000000000000000
> RDI=00007F440613D710 RSI=FFFFFFFFFFDF3B65 RAX=0000000000000000 RBX=00007F4406141390
> RCX=0000000000000026 RDX=0000000000000001 R8=00007F44CCF4EA52 R9=0000000000000000
> R10=00007F4406145740 R11=0000000000000003 R12=00007F44076AEF00 R13=0000000000000000
> R14=0000000000000000 R15=0000000000000000
> RIP=00007F44CCD0509E GS=0000 FS=0000 RSP=00007F44C9A84C20
> EFlags=0000000000210246 CS=0033 RBP=0000000000000000 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f44003b6e6f (f: 3894895,000000, d: 6,913462e-310)
> xmm1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm2 616c2f6176616a4c (f: 1986095744,000000, d: 1,981285e+161)
> xmm3 6a00656c62617468 (f: 1650553984,000000, d: 4,016150e+202)
> xmm4 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm5 03d303d203d103d0 (f: 64029648,000000, d: 3,048729e-290)
> xmm6 49676e697274532f (f: 1920226048,000000, d: 4,180283e+45)
> xmm7 4573646e756f4266 (f: 1970225792,000000, d: 3,751018e+26)
> xmm8 03d603d503d403d3 (f: 64226260,000000, d: 3,529736e-290)
> xmm9 03de03dd03dc03db (f: 64750556,000000, d: 4,812424e-290)
> xmm10 03e603e503e403e3 (f: 65274852,000000, d: 7,059551e-290)
> xmm11 03ee03ed03ec03eb (f: 65799148,000000, d: 9,624926e-290)
> xmm12 03f603f503f403f3 (f: 66323444,000000, d: 1,411926e-289)
> xmm13 03fe03fd03fc03fb (f: 66847740,000000, d: 1,925001e-289)
> xmm14 0406040504040403 (f: 67372032,000000, d: 2,823883e-289)
> xmm15 040e040d040c040b (f: 67896328,000000, d: 3,850033e-289)
> Module=/opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so
> Module_base_address=00007F44CC5BC000
> Method_being_compiled=org/jboss/as/controller/OperationContextImpl$ContextServiceBuilder.install()Lorg/jboss/msc/service/ServiceController;
> Target=2_80_20150630_255633 (Linux 4.1.6-201.fc22.x86_64)
> CPU=amd64 (8 logical CPUs) (0x3d3def000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F44CCD0509E [libj9jit28.so+0x74909e])
> (0x00007F44CCD05372 [libj9jit28.so+0x749372])
> (0x00007F44CC9F3922 [libj9jit28.so+0x437922])
> (0x00007F44CC9F45BB [libj9jit28.so+0x4385bb])
> (0x00007F44CCA04E10 [libj9jit28.so+0x448e10])
> (0x00007F44CCA05855 [libj9jit28.so+0x449855])
> (0x00007F44CCA09D5D [libj9jit28.so+0x44dd5d])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA0AC75 [libj9jit28.so+0x44ec75])
> (0x00007F44CCA0AFFB [libj9jit28.so+0x44effb])
> (0x00007F44CC88994D [libj9jit28.so+0x2cd94d])
> (0x00007F44CC889C19 [libj9jit28.so+0x2cdc19])
> (0x00007F44CC88AE94 [libj9jit28.so+0x2cee94])
> (0x00007F44CCD8348B [libj9jit28.so+0x7c748b])
> (0x00007F44CCD8AE4C [libj9jit28.so+0x7cee4c])
> (0x00007F44CC6C87B5 [libj9jit28.so+0x10c7b5])
> (0x00007F44CC6C9CAB [libj9jit28.so+0x10dcab])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CBDF0 [libj9jit28.so+0x10fdf0])
> (0x00007F44CC6CD0ED [libj9jit28.so+0x1110ed])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CDA04 [libj9jit28.so+0x111a04])
> (0x00007F44D8F8E9EC [libj9thr28.so+0x99ec])
> (0x00007F44DAFD0555 [libpthread.so.0+0x7555])
> clone+0x6d (0x00007F44DA8F0B9D [libc.so.6+0x102b9d])
> {panel}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 05:46:00 2015
From: issues at jboss.org (George Leon (JIRA))
Date: Fri, 18 Sep 2015 05:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5362) Wildfly 9.0.1 Final fails
 next day with WFLYDS0032: Failed to list files in directory
In-Reply-To: <JIRA.12585348.1442569528000@Atlassian.JIRA>
References: <JIRA.12585348.1442569528000@Atlassian.JIRA>
	<JIRA.12585348.1442569528224@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585348.1442569528000.44087.1442569560219@Atlassian.JIRA>

George Leon created WFLY-5362:
---------------------------------

             Summary:  Wildfly 9.0.1 Final fails  next day  with WFLYDS0032: Failed to list files in directory
                 Key: WFLY-5362
                 URL: https://issues.jboss.org/browse/WFLY-5362
             Project: WildFly
          Issue Type: Bug
         Environment: Wildfly 9.0.1 Final
            Reporter: George Leon
            Assignee: Jason Greene


Hi  all,

First Wildlfly is the best  Bravo  from Greece .

 

 

We have  wildfly 9.0.1 Final    installed    as  root   and all folders are  owner root  

we deployed our  web app (war) via the Web UI administration   everything  works  for several hours  the next day   we come to work  and  Wildlfly  fails   with error below   any help is very welcome

 

ls          /opt/wildfly-9.0.1.Final/standalone/deployments

drwxr-xr-x. 3 root root 4096 Sep 16 14:24 configuration

drwxr-xr-x. 8 root root 4096 Sep 10 11:20 data

drwxr-xr-x. 2 root root   23 Jul 23 21:01 deployments

drwxr-xr-x. 3 root root   16 Jul 23 21:01 lib

drwxr-xr-x. 2 root root 4096 Sep 18 00:00 log

drwxr-xr-x. 7 root root   94 Sep 16 14:24 tmp

 

 

2015-09-18 10:02:41,735 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/wildfly-9.0.1.Final/standalone/deployments threw Exception: java.lang.RuntimeException: WFLYDS0032: Failed to list files in directory /opt/wildfly-9.0.1.Final/standalone/deployments. Check that the contents of the directory are readable.

    at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.listDirectoryChildren(FileSystemDeploymentService.java:1170)

    at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scanDirectory(FileSystemDeploymentService.java:664)

    at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:474)

    at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:393)

    at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:161)

    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)

    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)

    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)

    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)

 

 

Thanks 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 05:58:00 2015
From: issues at jboss.org (Kylin Soong (JIRA))
Date: Fri, 18 Sep 2015 05:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-913) NPE if use
	LdapExtLoginModule in j2se
In-Reply-To: <JIRA.12585352.1442570272000@Atlassian.JIRA>
References: <JIRA.12585352.1442570272000@Atlassian.JIRA>
	<JIRA.12585352.1442570272493@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585352.1442570272000.44112.1442570280106@Atlassian.JIRA>

Kylin Soong created SECURITY-913:
------------------------------------

             Summary: NPE if use LdapExtLoginModule in j2se
                 Key: SECURITY-913
                 URL: https://issues.jboss.org/browse/SECURITY-913
             Project: PicketBox 
          Issue Type: Enhancement
          Components: JBossSX
    Affects Versions: PicketBox_5_0_0.Alpha1
            Reporter: Kylin Soong
            Assignee: Kylin Soong
             Fix For: PicketBox_5_0_0.Alpha1


Use LdapExtLoginModule in j2se with condifg:
{code}
<?xml version='1.0'?> 
 
<policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="urn:jboss:security-config:5.0"
         xmlns="urn:jboss:security-config:5.0"
         xmlns:jbxb="urn:jboss:security-config:5.0">
         
    <application-policy name = "Sample-Ldap"> 
       <authentication>
          <login-module code = "org.jboss.security.auth.spi.LdapExtLoginModule" flag = "required">  
              <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
              <module-option name="java.naming.provider.url">ldap://10.66.218.46:389</module-option>
              <module-option name="java.naming.security.authentication">simple</module-option>
              <module-option name="bindDN">cn=Manager,dc=example,dc=com</module-option>
              <module-option name="bindCredential">redhat</module-option>
              <module-option name="baseCtxDN">ou=Customers,dc=example,dc=com</module-option>
              <module-option name="baseFilter">(uid={0})</module-option>
              <module-option name="rolesCtxDN">ou=Roles,dc=example,dc=com</module-option>
              <module-option name="roleFilter">(uniqueMember={1})</module-option>
              <module-option name="roleAttributeID">cn</module-option>
          </login-module> 
       </authentication> 
    </application-policy>  
     
</policy> 
{code}

authentication parse section code [1]  line 123:
{code}
AuthenticationInfo authInfo = new AuthenticationInfo();
{code}
which this cause null set as AuthenticationInfo name, then cause 'jboss.security.security_domain=null' as options be passed to LdapExtLoginModule, this null value finally cause NPE in LdapExtLoginModule line around 840
{code}
Entry entry = (Entry) iter.next();
env.put(entry.getKey(), entry.getValue());
{code}

[1] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/config/parser/ApplicationPolicyParser.java
[2] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/auth/spi/LdapExtLoginModule.java



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:13:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-379) Fix & re-enable ignored
	security tests
In-Reply-To: <JIRA.12488028.1364302655000@Atlassian.JIRA>
References: <JIRA.12488028.1364302655000@Atlassian.JIRA>
	<JIRA.12488028.1364302655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488028.1364302655000.44144.1442571180343@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-379:
----------------------------------
    Fix Version/s:     (was: 10.0.0.CR2)


> Fix & re-enable ignored security tests
> --------------------------------------
>
>                 Key: WFLY-379
>                 URL: https://issues.jboss.org/browse/WFLY-379
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>    Affects Versions: 8.0.0.Alpha1
>         Environment: AS8 with undertow
>            Reporter: Tomaz Cerar
>            Assignee: Darran Lofthouse
>
> AS8 with undertow fails few security tests.
> This issue is here just for tracking what they are so they can be fixed
> Still disabled tests:
> {noformat}
> SPNEGOLoginModuleTestCase
> AdvancedLdapLoginModuleTestCase
> StackingJASPITestCase
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:15:02 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4588) Elytron Integration
In-Reply-To: <JIRA.12570716.1430827075000@Atlassian.JIRA>
References: <JIRA.12570716.1430827075000@Atlassian.JIRA>
	<JIRA.12570716.1430827075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570716.1430827075000.44153.1442571302197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-4588:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Elytron Integration
> -------------------
>
>                 Key: WFLY-4588
>                 URL: https://issues.jboss.org/browse/WFLY-4588
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> Building on WFCORE-673 this is the top level task to cover integration in WildFly
> The majority should be building on top of the work in core but there will be some WildFly specifics to consider.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:15:02 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1598) Out of the box SSL - or
	shortly after.
In-Reply-To: <JIRA.12495221.1372327189000@Atlassian.JIRA>
References: <JIRA.12495221.1372327189000@Atlassian.JIRA>
	<JIRA.12495221.1372327189000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495221.1372327189000.44162.1442571302393@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1598:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Out of the box SSL - or shortly after.
> --------------------------------------
>
>                 Key: WFLY-1598
>                 URL: https://issues.jboss.org/browse/WFLY-1598
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: management_security,, management_sso
>             Fix For: 11.0.0.Alpha1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
>  - If we ship a default keystore then everyone has access to the private key.
>  - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:15:02 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-319) OpenSSL SSL certificate
 support for domain management security realms (http and native interface)
In-Reply-To: <JIRA.12463462.1333723487000@Atlassian.JIRA>
References: <JIRA.12463462.1333723487000@Atlassian.JIRA>
	<JIRA.12463462.1333723487000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463462.1333723487000.44168.1442571302595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-319:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> OpenSSL SSL certificate support for domain management security realms (http and native interface)
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-319
>                 URL: https://issues.jboss.org/browse/WFLY-319
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security, Server
>            Reporter: Franck LEDAY
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> related to https://community.jboss.org/message/728665#728665 : 
> Request the feature to use SSL certificate issued from OpenSSL directly from SSL attribute of management interface instead of available use of JKS .



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:15:02 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove
 WebSecurityJBossWebXmlSecurityRolesTestCase
In-Reply-To: <JIRA.12488273.1364495388000@Atlassian.JIRA>
References: <JIRA.12488273.1364495388000@Atlassian.JIRA>
	<JIRA.12488273.1364495388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488273.1364495388000.44174.1442571302796@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-383:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase
> -----------------------------------------------------------------
>
>                 Key: WFLY-383
>                 URL: https://issues.jboss.org/browse/WFLY-383
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Test Suite, Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid.
> I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:16:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-431) Revisit enforcement of
 required file system permissions.
In-Reply-To: <JIRA.12486809.1362763320000@Atlassian.JIRA>
References: <JIRA.12486809.1362763320000@Atlassian.JIRA>
	<JIRA.12486809.1362763320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486809.1362763320000.44178.1442571361132@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-431:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Revisit enforcement of required file system permissions.
> --------------------------------------------------------
>
>                 Key: WFLY-431
>                 URL: https://issues.jboss.org/browse/WFLY-431
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: management_security,
>             Fix For: 11.0.0.Alpha1
>
>
> Now that AS8 has moved to Java 7 we can re-visit the level of control we have over file system permissions, this can be from taking more control of the local authentication mechanism to ensure incorrect permissions are not inherited to verifying sensitive configuration files are not world readable.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:16:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-421) Domain Mode JMX access through
 the HostController
In-Reply-To: <JIRA.12460611.1330692815000@Atlassian.JIRA>
References: <JIRA.12460611.1330692815000@Atlassian.JIRA>
	<JIRA.12460611.1330692815000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460611.1330692815000.44183.1442571361233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-421:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Domain Mode JMX access through the HostController
> -------------------------------------------------
>
>                 Key: WFLY-421
>                 URL: https://issues.jboss.org/browse/WFLY-421
>             Project: WildFly
>          Issue Type: Task
>          Components: JMX, Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: JMX, investigation_required
>             Fix For: 11.0.0.Alpha1
>
>
> This task is first to review if this should be considered.
> At the moment access to JMX is provided through the remoting connector of each AS instance - this task is to consider if we should actually make it available through the host controller with the host controller acting as a proxy.
> The main motivation being to separate management and app traffic.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:16:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-466) Detect JBossWS Configuration
 for @PermitAll endpoints within Undertow subsystem.
In-Reply-To: <JIRA.12489705.1366199995000@Atlassian.JIRA>
References: <JIRA.12489705.1366199995000@Atlassian.JIRA>
	<JIRA.12489705.1366199995000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489705.1366199995000.44189.1442571361399@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-466:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-466
>                 URL: https://issues.jboss.org/browse/WFLY-466
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container.
> This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:16:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-447) Connection Reauthentication
 and Security Propagation
In-Reply-To: <JIRA.12478814.1352367103000@Atlassian.JIRA>
References: <JIRA.12478814.1352367103000@Atlassian.JIRA>
	<JIRA.12478814.1352367103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478814.1352367103000.44204.1442571361806@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-447:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Connection Reauthentication and Security Propagation
> ----------------------------------------------------
>
>                 Key: WFLY-447
>                 URL: https://issues.jboss.org/browse/WFLY-447
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: authentication_service
>             Fix For: 11.0.0.Alpha1
>
>
> This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting.  
> This is to predominantly cover two major scenarios: -
>  - Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user.
>  - Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as.
> The following document is building up the requirements and design considerations and decisions: -
> https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPropagation



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:16:02 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-442) Review of AccessController and
 PrivilegedAction use across AS7
In-Reply-To: <JIRA.12482399.1357892166000@Atlassian.JIRA>
References: <JIRA.12482399.1357892166000@Atlassian.JIRA>
	<JIRA.12482399.1357892166000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482399.1357892166000.44211.1442571362052@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-442:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Review of AccessController and PrivilegedAction use across AS7
> --------------------------------------------------------------
>
>                 Key: WFLY-442
>                 URL: https://issues.jboss.org/browse/WFLY-442
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: investigation_required
>             Fix For: 11.0.0.Alpha1
>
>
> The following needs reviewing across AS7: -
>  - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable).
>  - Use of AccessController even though there is no SecurityManager set.
>  - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED
>  - Utility methods with visibility too high.
>  - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction.
>  - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:16:02 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-483) Allow more control over
 authentication for server to server communication through
 remote-outbound-connection
In-Reply-To: <JIRA.12469282.1340292148000@Atlassian.JIRA>
References: <JIRA.12469282.1340292148000@Atlassian.JIRA>
	<JIRA.12469282.1340292148000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469282.1340292148000.44243.1442571362772@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-483:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Allow more control over authentication for server to server communication through remote-outbound-connection
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-483
>                 URL: https://issues.jboss.org/browse/WFLY-483
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Remoting, Security
>            Reporter: jaikiran pai
>            Assignee: Darran Lofthouse
>              Labels: authentication_service
>             Fix For: 11.0.0.Alpha1
>
>
> Right now for server to server communication via a remote-outbound-connection, we expect a static username to be specified (along with the security realm). User applications which use this remote-outbound-connection, for example an EJB application, do not have much control over the user/pass information, since the username is static. This further acts a drawback since the username that's used to connect to the remote server will be used as the (application) user who invoked the EJB.
> It would be good to allow more control over the authentication for the remote-outbound-connection.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:16:03 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1136) Common mechanism for all
 secure socket definitions
In-Reply-To: <JIRA.12413600.1277840615000@Atlassian.JIRA>
References: <JIRA.12413600.1277840615000@Atlassian.JIRA>
	<JIRA.12413600.1277840615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12413600.1277840615000.44255.1442571363688@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1136:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Common mechanism for all secure socket definitions
> --------------------------------------------------
>
>                 Key: WFLY-1136
>                 URL: https://issues.jboss.org/browse/WFLY-1136
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> The JAASSecurityDomain in my opinion should
> >> handle all secure socket definitions. Mod-cluster currently does
> >> not support JAASSecurityDomains.
> I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:17:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-487) Verify audit implications and
	required APIs
In-Reply-To: <JIRA.12482333.1357812301000@Atlassian.JIRA>
References: <JIRA.12482333.1357812301000@Atlassian.JIRA>
	<JIRA.12482333.1357812301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482333.1357812301000.44261.1442571420482@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-487:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Verify audit implications and required APIs
> -------------------------------------------
>
>                 Key: WFLY-487
>                 URL: https://issues.jboss.org/browse/WFLY-487
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: authentication_service
>             Fix For: 11.0.0.Alpha1
>
>
> Auditing may be logging as the user that executes a request, if we have used a trust relationship for a request to be run as a different user we need to be able to track back to identify how the user for the request was selected.
> i.e. If userA runs something as userB and does something bad we must be able to track back that it was userA making the overall request without userB getting the blame.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:17:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-569) Implement an account lockout
 mechanism for domain management.
In-Reply-To: <JIRA.12446171.1314976732000@Atlassian.JIRA>
References: <JIRA.12446171.1314976732000@Atlassian.JIRA>
	<JIRA.12446171.1314976732000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446171.1314976732000.44264.1442571420531@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-569:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Implement an account lockout mechanism for domain management.
> -------------------------------------------------------------
>
>                 Key: WFLY-569
>                 URL: https://issues.jboss.org/browse/WFLY-569
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Common_Authentication, Realm_Management, management_security,
>             Fix For: 11.0.0.Alpha1
>
>
> One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: -
> - Consider an option to update the remote store if possible.
> - If not cache a backlisted user until an admin unlocks that account
> Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:17:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2552) Undertow
 AuthenticationMechanism Configuration Overrides
In-Reply-To: <JIRA.12525944.1385146370000@Atlassian.JIRA>
References: <JIRA.12525944.1385146370000@Atlassian.JIRA>
	<JIRA.12525944.1385146370000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525944.1385146370000.44273.1442571420770@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2552:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Undertow AuthenticationMechanism Configuration Overrides
> --------------------------------------------------------
>
>                 Key: WFLY-2552
>                 URL: https://issues.jboss.org/browse/WFLY-2552
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 11.0.0.Alpha1
>
>
> General article covering the security configuration for Undertow / WildFly: -
> https://community.jboss.org/wiki/UndertowSecurityConfiguration



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:17:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2440) Thread pool
 AccessControlContext Propagation
In-Reply-To: <JIRA.12518017.1383655122000@Atlassian.JIRA>
References: <JIRA.12518017.1383655122000@Atlassian.JIRA>
	<JIRA.12518017.1383655122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518017.1383655122000.44277.1442571420925@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2440:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Thread pool AccessControlContext Propagation
> --------------------------------------------
>
>                 Key: WFLY-2440
>                 URL: https://issues.jboss.org/browse/WFLY-2440
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> A decision was made within Java that newly created threads should inherit the access control context of their creator.  
> In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have.
> Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread.
> This may affect components outside of WildFly but I am raising it here as a top level task.
> Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:17:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2955) Audit logging should also be
 able to use PKCS#11 for keystores.
In-Reply-To: <JIRA.12532489.1392726585000@Atlassian.JIRA>
References: <JIRA.12532489.1392726585000@Atlassian.JIRA>
	<JIRA.12532489.1392726585000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532489.1392726585000.44280.1442571420992@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2955:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Audit logging should also be able to use PKCS#11 for keystores.
> ---------------------------------------------------------------
>
>                 Key: WFLY-2955
>                 URL: https://issues.jboss.org/browse/WFLY-2955
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:18:00 2015
From: issues at jboss.org (Kylin Soong (JIRA))
Date: Fri, 18 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-913) NPE if use
	LdapExtLoginModule in j2se
In-Reply-To: <JIRA.12585352.1442570272000@Atlassian.JIRA>
References: <JIRA.12585352.1442570272000@Atlassian.JIRA>
	<JIRA.12585352.1442570272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585352.1442570272000.44282.1442571480437@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kylin Soong updated SECURITY-913:
---------------------------------
    Attachment: picketbox-j2se.zip


h2. How to reproduce
{code}
$ unzip picketbox-j2se.zip
$ cd picketbox-j2se
$ mvn clean install dependency:copy-dependencies
$ java -cp target/dependency/*:target/picketbox-loginModule-j2se.jar ReproduceMain
{code}

Run LoginException will throw

> NPE if use LdapExtLoginModule in j2se
> -------------------------------------
>
>                 Key: SECURITY-913
>                 URL: https://issues.jboss.org/browse/SECURITY-913
>             Project: PicketBox 
>          Issue Type: Enhancement
>          Components: JBossSX
>    Affects Versions: PicketBox_5_0_0.Alpha1
>            Reporter: Kylin Soong
>            Assignee: Kylin Soong
>             Fix For: PicketBox_5_0_0.Alpha1
>
>         Attachments: picketbox-j2se.zip
>
>
> Use LdapExtLoginModule in j2se with condifg:
> {code}
> <?xml version='1.0'?> 
>  
> <policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>          xsi:schemaLocation="urn:jboss:security-config:5.0"
>          xmlns="urn:jboss:security-config:5.0"
>          xmlns:jbxb="urn:jboss:security-config:5.0">
>          
>     <application-policy name = "Sample-Ldap"> 
>        <authentication>
>           <login-module code = "org.jboss.security.auth.spi.LdapExtLoginModule" flag = "required">  
>               <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
>               <module-option name="java.naming.provider.url">ldap://10.66.218.46:389</module-option>
>               <module-option name="java.naming.security.authentication">simple</module-option>
>               <module-option name="bindDN">cn=Manager,dc=example,dc=com</module-option>
>               <module-option name="bindCredential">redhat</module-option>
>               <module-option name="baseCtxDN">ou=Customers,dc=example,dc=com</module-option>
>               <module-option name="baseFilter">(uid={0})</module-option>
>               <module-option name="rolesCtxDN">ou=Roles,dc=example,dc=com</module-option>
>               <module-option name="roleFilter">(uniqueMember={1})</module-option>
>               <module-option name="roleAttributeID">cn</module-option>
>           </login-module> 
>        </authentication> 
>     </application-policy>  
>      
> </policy> 
> {code}
> authentication parse section code [1]  line 123:
> {code}
> AuthenticationInfo authInfo = new AuthenticationInfo();
> {code}
> which this cause null set as AuthenticationInfo name, then cause 'jboss.security.security_domain=null' as options be passed to LdapExtLoginModule, this null value finally cause NPE in LdapExtLoginModule line around 840
> {code}
> Entry entry = (Entry) iter.next();
> env.put(entry.getKey(), entry.getValue());
> {code}
> [1] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/config/parser/ApplicationPolicyParser.java
> [2] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/auth/spi/LdapExtLoginModule.java



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2953) Add support to specify
 security provider for key and trust stores used by HornetQ
In-Reply-To: <JIRA.12532480.1392722055000@Atlassian.JIRA>
References: <JIRA.12532480.1392722055000@Atlassian.JIRA>
	<JIRA.12532480.1392722055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532480.1392722055000.44285.1442571480527@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2953:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Add support to specify security provider for key and trust stores used by HornetQ
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2953
>                 URL: https://issues.jboss.org/browse/WFLY-2953
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2567) Custom authentication
 mechanism definition - Subsystem Level
In-Reply-To: <JIRA.12526043.1385388220000@Atlassian.JIRA>
References: <JIRA.12526043.1385388220000@Atlassian.JIRA>
	<JIRA.12526043.1385388220000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526043.1385388220000.44289.1442571480601@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2567:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Custom authentication mechanism definition - Subsystem Level
> ------------------------------------------------------------
>
>                 Key: WFLY-2567
>                 URL: https://issues.jboss.org/browse/WFLY-2567
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3064) Remove
 org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase
 test case.
In-Reply-To: <JIRA.12534003.1393958385000@Atlassian.JIRA>
References: <JIRA.12534003.1393958385000@Atlassian.JIRA>
	<JIRA.12534003.1393958385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534003.1393958385000.44292.1442571480651@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3064:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case.
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3064
>                 URL: https://issues.jboss.org/browse/WFLY-3064
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> A new test case was added under WFLY-3063 that demonstrates the correct way to do this so now remove the original way that depended on internal APIs.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3491) All key and trust stores
 should be reloadable.
In-Reply-To: <JIRA.12543729.1402657919000@Atlassian.JIRA>
References: <JIRA.12543729.1402657919000@Atlassian.JIRA>
	<JIRA.12543729.1402657919000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543729.1402657919000.44295.1442571480721@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3491:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> All key and trust stores should be reloadable.
> ----------------------------------------------
>
>                 Key: WFLY-3491
>                 URL: https://issues.jboss.org/browse/WFLY-3491
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> Some stores may need to be self re-loading e.g. detect filesystem changes - others could be on demand via a management op.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3224) SSL The Last Round
In-Reply-To: <JIRA.12537340.1396722411000@Atlassian.JIRA>
References: <JIRA.12537340.1396722411000@Atlassian.JIRA>
	<JIRA.12537340.1396722411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12537340.1396722411000.44300.1442571480842@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3224:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> SSL The Last Round
> ------------------
>
>                 Key: WFLY-3224
>                 URL: https://issues.jboss.org/browse/WFLY-3224
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> I could probably list most components in the components box, anyway this is a top level task to contain all of the SSL enhancements required so that they can be addressed once and for all.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:18:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4304) Servlet authentication kicked
 off when *not* a part of any security-constraint
In-Reply-To: <JIRA.12562245.1422906276000@Atlassian.JIRA>
References: <JIRA.12562245.1422906276000@Atlassian.JIRA>
	<JIRA.12562245.1422906276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562245.1422906276000.44306.1442571481005@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-4304:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-4304
>                 URL: https://issues.jboss.org/browse/WFLY-4304
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.2.0.Final
>            Reporter: Brett Meyer
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth.  If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header.  In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case.  However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped.  I'm not currently able to figure out exactly where that's occurring...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4872) Add the Elytron subsystem to
 the feature packs
In-Reply-To: <JIRA.12577134.1436206186000@Atlassian.JIRA>
References: <JIRA.12577134.1436206186000@Atlassian.JIRA>
	<JIRA.12577134.1436206186000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577134.1436206186000.44309.1442571540480@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-4872:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Add the Elytron subsystem to the feature packs
> ----------------------------------------------
>
>                 Key: WFLY-4872
>                 URL: https://issues.jboss.org/browse/WFLY-4872
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Build System
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-210) Point to explicit security doc
 in server.log
In-Reply-To: <JIRA.12450346.1319565767000@Atlassian.JIRA>
References: <JIRA.12450346.1319565767000@Atlassian.JIRA>
	<JIRA.12450346.1319565767000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450346.1319565767000.44314.1442571540577@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-210:
----------------------------------
    Fix Version/s:     (was: 10.0.0.CR2)


> Point to explicit security doc in server.log
> --------------------------------------------
>
>                 Key: WFLY-210
>                 URL: https://issues.jboss.org/browse/WFLY-210
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Server
>         Environment: Thinkpad T510 w/ 4 cores, 8Gb, running CSB
>            Reporter: Chuck Mosher
>            Assignee: Darran Lofthouse
>            Priority: Minor
>              Labels: eap6-ux
>
> Nice to warn me (in the server.log) that I have a security issue due to the cluster admin/user pwd using the defaults.  Warning tells me to look at the docs; would it be possible to put it the hyperlink to the specific doc?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3659) DIGEST authentication method
 throws javax.security.auth.callback.UnsupportedCallbackException
In-Reply-To: <JIRA.12547249.1406113915000@Atlassian.JIRA>
References: <JIRA.12547249.1406113915000@Atlassian.JIRA>
	<JIRA.12547249.1406113915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547249.1406113915000.44321.1442571540690@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3659:
-----------------------------------
    Priority: Major  (was: Blocker)


> DIGEST authentication method throws javax.security.auth.callback.UnsupportedCallbackException
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3659
>                 URL: https://issues.jboss.org/browse/WFLY-3659
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.1.0.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Joseph Hwang
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> Password encryption in database login module with wildfly digest login config throws {{javax.security.auth.callback.UnsupportedCallbackException}}. These are sources.
> {code:xml|title=web.xml|borderStyle=solid}
> <security-role>
>       <role-name>administrator</role-name>
> </security-role>
> <login-config>
>       <auth-method>DIGEST</auth-method>
>       <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> {code}
> {code:xml|title=jboss-web.xml|borderStyle=solid}
> <jboss-web>
>     <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> {code}
> {code:xml|title=standalone.xml|borderStyle=solid}
> <security-domain name="my_secure_domain" cache-type="default">
>      <authentication>
>           <login-module code="Database" flag="required">
>                <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
>                <module-option name="principalsQuery" value="select password from credential where uid=?"/>
>                <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
>                <module-option name="hashAlgorithm" value="MD5"/>
>                <module-option name="hashEncoding" value="RFC2617"/>
>                <module-option name="hashUserPassword" value="false"/>
>                <module-option name="hashStorePassword" value="true"/>
>                <module-option name="passwordIsA1Hash" value="true"/>
>                <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
>                <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
>           </login-module>
>      </authentication>
> </security-domain>
> {code}
> Password is encrypted with below codes
> {code:java|title=EncryptPassword.java|borderStyle=solid}
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
>     public static void main(String[] args) {
>         // TODO Auto-generated method stub
>         String userName="admin"; 
>         String realmName="WildFly8DigestRealm"; 
>         String password="passwd123"; 
>         String clearTextPassword=userName+":"+realmName+":"+password;  
>         String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
>         System.out.println("clearTextPassword: "+clearTextPassword); 
>         System.out.println("hashedPassword: "+hashedPassword); 
>     }
> }
> {code}
> But login failed! The log shows the folowing exceptions :
> {code}
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
>  at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  ... 49 more
> {code}
> This cofiguration worked well in JBoss AS 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3659) DIGEST authentication method
 throws javax.security.auth.callback.UnsupportedCallbackException
In-Reply-To: <JIRA.12547249.1406113915000@Atlassian.JIRA>
References: <JIRA.12547249.1406113915000@Atlassian.JIRA>
	<JIRA.12547249.1406113915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547249.1406113915000.44328.1442571540816@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-3659:
-----------------------------------
    Fix Version/s: 10.0.0.CR2


> DIGEST authentication method throws javax.security.auth.callback.UnsupportedCallbackException
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3659
>                 URL: https://issues.jboss.org/browse/WFLY-3659
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.1.0.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Joseph Hwang
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> Password encryption in database login module with wildfly digest login config throws {{javax.security.auth.callback.UnsupportedCallbackException}}. These are sources.
> {code:xml|title=web.xml|borderStyle=solid}
> <security-role>
>       <role-name>administrator</role-name>
> </security-role>
> <login-config>
>       <auth-method>DIGEST</auth-method>
>       <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> {code}
> {code:xml|title=jboss-web.xml|borderStyle=solid}
> <jboss-web>
>     <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> {code}
> {code:xml|title=standalone.xml|borderStyle=solid}
> <security-domain name="my_secure_domain" cache-type="default">
>      <authentication>
>           <login-module code="Database" flag="required">
>                <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
>                <module-option name="principalsQuery" value="select password from credential where uid=?"/>
>                <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
>                <module-option name="hashAlgorithm" value="MD5"/>
>                <module-option name="hashEncoding" value="RFC2617"/>
>                <module-option name="hashUserPassword" value="false"/>
>                <module-option name="hashStorePassword" value="true"/>
>                <module-option name="passwordIsA1Hash" value="true"/>
>                <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
>                <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
>           </login-module>
>      </authentication>
> </security-domain>
> {code}
> Password is encrypted with below codes
> {code:java|title=EncryptPassword.java|borderStyle=solid}
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
>     public static void main(String[] args) {
>         // TODO Auto-generated method stub
>         String userName="admin"; 
>         String realmName="WildFly8DigestRealm"; 
>         String password="passwd123"; 
>         String clearTextPassword=userName+":"+realmName+":"+password;  
>         String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword); 
>         System.out.println("clearTextPassword: "+clearTextPassword); 
>         System.out.println("hashedPassword: "+hashedPassword); 
>     }
> }
> {code}
> But login failed! The log shows the folowing exceptions :
> {code}
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
>  at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
>  at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
>  at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_60]
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
>  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
>  at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
>  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
>  ... 49 more
> {code}
> This cofiguration worked well in JBoss AS 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:34:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 06:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5363) [Migration operation] [Web to
 Undertow] Default value for access-log extended differs
In-Reply-To: <JIRA.12585358.1442572428000@Atlassian.JIRA>
References: <JIRA.12585358.1442572428000@Atlassian.JIRA>
	<JIRA.12585358.1442572428039@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585358.1442572428000.44382.1442572440524@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5363:
--------------------------------------

             Summary: [Migration operation] [Web to Undertow] Default value for access-log extended differs
                 Key: WFLY-5363
                 URL: https://issues.jboss.org/browse/WFLY-5363
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Critical


When migrating access-log without defined extended attribute results in undertow without defined extended attribute, but the default values differ causing that even though in Web subsystem extended format wasn't used, in Undertow it is expected logging to use extended format.

Ideally the defaults should be the same or the migrate operation needs to define the extended attribute to false if it wasn't defined in Web.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:34:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 06:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5363) [Migration operation] [Web to
 Undertow] Default value for access-log extended differs
In-Reply-To: <JIRA.12585358.1442572428000@Atlassian.JIRA>
References: <JIRA.12585358.1442572428000@Atlassian.JIRA>
	<JIRA.12585358.1442572428000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585358.1442572428000.44385.1442572440615@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-5363:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> [Migration operation] [Web to Undertow] Default value for access-log extended differs
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-5363
>                 URL: https://issues.jboss.org/browse/WFLY-5363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> When migrating access-log without defined extended attribute results in undertow without defined extended attribute, but the default values differ causing that even though in Web subsystem extended format wasn't used, in Undertow it is expected logging to use extended format.
> Ideally the defaults should be the same or the migrate operation needs to define the extended attribute to false if it wasn't defined in Web.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:35:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Fri, 18 Sep 2015 06:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5363) [Migration operation] [Web to
 Undertow] Default value for access-log extended attribute differs
In-Reply-To: <JIRA.12585358.1442572428000@Atlassian.JIRA>
References: <JIRA.12585358.1442572428000@Atlassian.JIRA>
	<JIRA.12585358.1442572428000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585358.1442572428000.44388.1442572500282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-5363:
-----------------------------------
    Summary: [Migration operation] [Web to Undertow] Default value for access-log extended attribute differs  (was: [Migration operation] [Web to Undertow] Default value for access-log extended differs)


> [Migration operation] [Web to Undertow] Default value for access-log extended attribute differs
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5363
>                 URL: https://issues.jboss.org/browse/WFLY-5363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> When migrating access-log without defined extended attribute results in undertow without defined extended attribute, but the default values differ causing that even though in Web subsystem extended format wasn't used, in Undertow it is expected logging to use extended format.
> Ideally the defaults should be the same or the migrate operation needs to define the extended attribute to false if it wasn't defined in Web.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 06:49:00 2015
From: issues at jboss.org (Kylin Soong (JIRA))
Date: Fri, 18 Sep 2015 06:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-914) Add a new
 DatabaseServerLoginModule for support run databse based authentication in
 j2se
In-Reply-To: <JIRA.12585359.1442573326000@Atlassian.JIRA>
References: <JIRA.12585359.1442573326000@Atlassian.JIRA>
	<JIRA.12585359.1442573326038@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585359.1442573326000.44439.1442573340100@Atlassian.JIRA>

Kylin Soong created SECURITY-914:
------------------------------------

             Summary: Add a new DatabaseServerLoginModule for support run databse based authentication in j2se
                 Key: SECURITY-914
                 URL: https://issues.jboss.org/browse/SECURITY-914
             Project: PicketBox 
          Issue Type: Feature Request
          Components: JBossSX
    Affects Versions: PicketBox_5_0_0.Alpha1
            Reporter: Kylin Soong
            Assignee: Stefan Guilhen


Current DatabaseServerLoginModule depend on DataSource, but if use LoginModule in j2se, it's feels inconvenience to set up a jndi server, so if add a new DatabaseServerLoginModule which accept db connection parameters(url, driver, username, password) as options, then it will be easy to integrate PicketBox in j2se environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 07:03:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 07:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-915) Migrate MessageFactory
 discovery to use ServiceLoader
In-Reply-To: <JIRA.12585365.1442574176000@Atlassian.JIRA>
References: <JIRA.12585365.1442574176000@Atlassian.JIRA>
	<JIRA.12585365.1442574176817@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585365.1442574176000.44510.1442574180855@Atlassian.JIRA>

Darran Lofthouse created SECURITY-915:
-----------------------------------------

             Summary: Migrate MessageFactory discovery to use ServiceLoader
                 Key: SECURITY-915
                 URL: https://issues.jboss.org/browse/SECURITY-915
             Project: PicketBox 
          Issue Type: Feature Request
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_3_0_0_CR1


At the moment we have statically defined class names and attempt to load them in turn to identify which ones are actually available - ServiceLoader based discovery would eliminate this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 07:24:00 2015
From: issues at jboss.org (Jan Stourac (JIRA))
Date: Fri, 18 Sep 2015 07:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5364) HTTP2 stream ID is not
 checked for some frame types
In-Reply-To: <JIRA.12585368.1442575351000@Atlassian.JIRA>
References: <JIRA.12585368.1442575351000@Atlassian.JIRA>
	<JIRA.12585368.1442575351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585368.1442575351000.44565.1442575440228@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Stourac moved JBEAP-1109 to WFLY-5364:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5364  (was: JBEAP-1109)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR10 (Alpha))


> HTTP2 stream ID is not checked for some frame types
> ---------------------------------------------------
>
>                 Key: WFLY-5364
>                 URL: https://issues.jboss.org/browse/WFLY-5364
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>
> According to [RFC7540|https://tools.ietf.org/html/rfc7540] frame types DATA and HEADERS are associated with particular data stream, therefore if its stream id is 0 this should be processed as PROTOCOL_ERROR.
> Similarly frames of types GOAWAY and SETTINGS must not be associated with particular stream id other than 0, if so then PROTOCOL_ERROR should be raised.
> With current implementation this requirement is not checked causing discrepation against RFC specification.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 07:30:00 2015
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 18 Sep 2015 07:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5365) Upgrade Narayana to
	5.0.7.Final
In-Reply-To: <JIRA.12585370.1442575756000@Atlassian.JIRA>
References: <JIRA.12585370.1442575756000@Atlassian.JIRA>
	<JIRA.12585370.1442575756098@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585370.1442575756000.44578.1442575800328@Atlassian.JIRA>

Michael Musgrove created WFLY-5365:
--------------------------------------

             Summary: Upgrade Narayana to 5.0.7.Final
                 Key: WFLY-5365
                 URL: https://issues.jboss.org/browse/WFLY-5365
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Transactions
    Affects Versions: 9.0.0.CR2
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 9.x.x TBD


WFLY-5261 reports that the :reload operation on the server fails because the transaction subsystem does not stop correctly and fails to restart. We have created another release (5.0.7.Final) containing just the fix for https://issues.jboss.org/browse/JBTM-2514





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 09:16:02 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 18 Sep 2015 09:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-923) Execution timeout for CLI
	operations
In-Reply-To: <JIRA.12582757.1440656755000@Atlassian.JIRA>
References: <JIRA.12582757.1440656755000@Atlassian.JIRA>
	<JIRA.12582757.1440656755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582757.1440656755000.44935.1442582162779@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110427#comment-13110427 ] 

Alexey Loubyansky commented on WFCORE-923:
------------------------------------------

What would you like the CLI to do in the case when deploy takes longer than expected? E.g.
Log a warning that it's taking too long.
Log an error and try to somehow undo the command.
Does the deploy actually succeed in your case even if it takes too long?

Thanks,
Alexey

> Execution timeout for CLI operations
> ------------------------------------
>
>                 Key: WFCORE-923
>                 URL: https://issues.jboss.org/browse/WFCORE-923
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Lyle Wang
>            Assignee: Alexey Loubyansky
>              Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy"  inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 09:37:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 18 Sep 2015 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1292) Usage of recover-credential
 for datasource does not take an effect
In-Reply-To: <JIRA.12585386.1442583368000@Atlassian.JIRA>
References: <JIRA.12585386.1442583368000@Atlassian.JIRA>
	<JIRA.12585386.1442583368404@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585386.1442583368000.44982.1442583420281@Atlassian.JIRA>

Ond?ej Chaloupka created JBJCA-1292:
---------------------------------------

             Summary: Usage of recover-credential for datasource does not take an effect
                 Key: JBJCA-1292
                 URL: https://issues.jboss.org/browse/JBJCA-1292
             Project: IronJacamar
          Issue Type: Bug
            Reporter: Ond?ej Chaloupka
            Assignee: Jesper Pedersen


XA datasource configured to use username and password for authentication to database does not consider usage of credential configuration for recovery. When using for example

{code}
<security>
  <user-name>user0</user-name>
  <password>user0</password>
</security>
<recovery>
  <recover-credential>
    <user-name>userrecover</user-name>
    <password>userrecover</password>
  </recover-credential>
</recovery>
{code}

then recovery for such datasource is trying to be processed with user {{user0}} instead of {{userrecover}} as expected.

This is a counter part to issue n EAP6 where the same functionality does not work as well. The bz and discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=1021547

Experiencing error
{code}
ERROR [org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon] (EJB default - 2) Cannot start recovering on xares: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
 at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
 at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
 at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
 at org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon.wipeOutTxsInDoubt(CrashHelperCommon.java:72)
 at org.jboss.as.test.jbossts.crashrec.jpa.JPACrashHelper.wipeOutTxsInDoubt(JPACrashHelper.java:59)
 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: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.invokeInNoTx(CMTTxInterceptor.java:263)
 at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
 at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
 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.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.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:195)
 at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
 at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
 at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
 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:745)
 at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 09:41:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 18 Sep 2015 09:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1292) Usage of recover-credential
 for datasource does not take an effect
In-Reply-To: <JIRA.12585386.1442583368000@Atlassian.JIRA>
References: <JIRA.12585386.1442583368000@Atlassian.JIRA>
	<JIRA.12585386.1442583368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585386.1442583368000.44987.1442583660087@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated JBJCA-1292:
------------------------------------
    Attachment: server.log


> Usage of recover-credential for datasource does not take an effect
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1292
>                 URL: https://issues.jboss.org/browse/JBJCA-1292
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jesper Pedersen
>         Attachments: server.log
>
>
> XA datasource configured to use username and password for authentication to database does not consider usage of credential configuration for recovery. When using for example
> {code}
> <security>
>   <user-name>user0</user-name>
>   <password>user0</password>
> </security>
> <recovery>
>   <recover-credential>
>     <user-name>userrecover</user-name>
>     <password>userrecover</password>
>   </recover-credential>
> </recovery>
> {code}
> then recovery for such datasource is trying to be processed with user {{user0}} instead of {{userrecover}} as expected.
> This is a counter part to issue n EAP6 where the same functionality does not work as well. The bz and discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=1021547
> Experiencing error
> {code}
> ERROR [org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon] (EJB default - 2) Cannot start recovering on xares: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
>  at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
>  at org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon.wipeOutTxsInDoubt(CrashHelperCommon.java:72)
>  at org.jboss.as.test.jbossts.crashrec.jpa.JPACrashHelper.wipeOutTxsInDoubt(JPACrashHelper.java:59)
>  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: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.invokeInNoTx(CMTTxInterceptor.java:263)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
>  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.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.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:195)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
>  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:745)
>  at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 09:52:00 2015
From: issues at jboss.org (Thorsten Moeller (JIRA))
Date: Fri, 18 Sep 2015 09:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5366) Startup success detection
 mechanism fails if JBOSS_HOME and jboss.server.base.dir are set
 differently.
In-Reply-To: <JIRA.12585389.1442584310000@Atlassian.JIRA>
References: <JIRA.12585389.1442584310000@Atlassian.JIRA>
	<JIRA.12585389.1442584310532@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585389.1442584310000.45049.1442584320386@Atlassian.JIRA>

Thorsten Moeller created WFLY-5366:
--------------------------------------

             Summary: Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
                 Key: WFLY-5366
                 URL: https://issues.jboss.org/browse/WFLY-5366
             Project: WildFly
          Issue Type: Bug
          Components: Scripts
    Affects Versions: 10.0.0.CR1
         Environment: Linux/Debian
            Reporter: Thorsten Moeller
            Assignee: Tomaz Cerar
            Priority: Critical


If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.

Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.

I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 10:02:00 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 18 Sep 2015 10:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1292) Usage of recover-credential
 for datasource does not take an effect
In-Reply-To: <JIRA.12585386.1442583368000@Atlassian.JIRA>
References: <JIRA.12585386.1442583368000@Atlassian.JIRA>
	<JIRA.12585386.1442583368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585386.1442583368000.45062.1442584920135@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110445#comment-13110445 ] 

Jesper Pedersen commented on JBJCA-1292:
----------------------------------------

I don't see https://github.com/ironjacamar/ironjacamar/blob/1.2/deployers/src/main/java/org/jboss/jca/deployers/common/AbstractDsDeployer.java#L1040 in server.log + the actual activation metadata

> Usage of recover-credential for datasource does not take an effect
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1292
>                 URL: https://issues.jboss.org/browse/JBJCA-1292
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jesper Pedersen
>         Attachments: server.log
>
>
> XA datasource configured to use username and password for authentication to database does not consider usage of credential configuration for recovery. When using for example
> {code}
> <security>
>   <user-name>user0</user-name>
>   <password>user0</password>
> </security>
> <recovery>
>   <recover-credential>
>     <user-name>userrecover</user-name>
>     <password>userrecover</password>
>   </recover-credential>
> </recovery>
> {code}
> then recovery for such datasource is trying to be processed with user {{user0}} instead of {{userrecover}} as expected.
> This is a counter part to issue n EAP6 where the same functionality does not work as well. The bz and discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=1021547
> Experiencing error
> {code}
> ERROR [org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon] (EJB default - 2) Cannot start recovering on xares: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
>  at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
>  at org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon.wipeOutTxsInDoubt(CrashHelperCommon.java:72)
>  at org.jboss.as.test.jbossts.crashrec.jpa.JPACrashHelper.wipeOutTxsInDoubt(JPACrashHelper.java:59)
>  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: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.invokeInNoTx(CMTTxInterceptor.java:263)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
>  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.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.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:195)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
>  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:745)
>  at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:03:00 2015
From: issues at jboss.org (Jan Stourac (JIRA))
Date: Fri, 18 Sep 2015 10:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5367) Possible
 ArrayIndexOutOfBoundsException in HTTP2 HPACK implementation
In-Reply-To: <JIRA.12585391.1442584942000@Atlassian.JIRA>
References: <JIRA.12585391.1442584942000@Atlassian.JIRA>
	<JIRA.12585391.1442584942000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585391.1442584942000.45079.1442584980801@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Stourac moved JBEAP-1112 to WFLY-5367:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5367  (was: JBEAP-1112)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR10 (Alpha))


> Possible ArrayIndexOutOfBoundsException in HTTP2 HPACK implementation
> ---------------------------------------------------------------------
>
>                 Key: WFLY-5367
>                 URL: https://issues.jboss.org/browse/WFLY-5367
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>
> When decoding really huge number via [Hpack.decodeInteger()|https://github.com/undertow-io/undertow/blob/90789748d3b493d7a233a4ef5ba8ae33032c1543/core/src/main/java/io/undertow/protocols/http2/Hpack.java#L150] there is possible ArrayIndexOutOfBoundsException caused by unchecked index variable "m" into array on [this line|https://github.com/undertow-io/undertow/blob/90789748d3b493d7a233a4ef5ba8ae33032c1543/core/src/main/java/io/undertow/protocols/http2/Hpack.java#L175] .
> There should be some check that "m" is not greater than PREFIX_TABLE.length-1.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 10:04:00 2015
From: issues at jboss.org (Jan Moravec (JIRA))
Date: Fri, 18 Sep 2015 10:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5368) WFLYSRV0099: 'myappname:main'
 cannot be loaded from a ServiceModuleLoader as its name does not start with
 'deployment.'
In-Reply-To: <JIRA.12585392.1442585021000@Atlassian.JIRA>
References: <JIRA.12585392.1442585021000@Atlassian.JIRA>
	<JIRA.12585392.1442585021744@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585392.1442585021000.45082.1442585040098@Atlassian.JIRA>

Jan Moravec created WFLY-5368:
---------------------------------

             Summary: WFLYSRV0099: 'myappname:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'
                 Key: WFLY-5368
                 URL: https://issues.jboss.org/browse/WFLY-5368
             Project: WildFly
          Issue Type: Bug
          Components: Web (JBoss Web)
    Affects Versions: 9.0.1.Final
         Environment: Windows 7 Ultimate
JDK 1.7.0_55 (Oracle)
            Reporter: Jan Moravec
            Assignee: Remy Maucherat
            Priority: Critical
         Attachments: server.log

Hello,
I am moving our apps from JBoss 7 Community to WildFly 9.0.1 and hitting the following error during the deployment of our apps:

WFLYSRV0099: 'quartzdesk-test-quartz-v2-2-x-logback:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'

I tried 2 different applications that all work without any problem on various popular application servers/containers, but with the same result. I tried to google this error, but did not find much information.

Any idea what is going on?

Many thanks.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 10:09:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Fri, 18 Sep 2015 10:09:00 -0400 (EDT)
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.45095.1442585340309@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105682#comment-13105682 ] 

Ladislav Thon edited comment on WFLY-5092 at 9/18/15 10:08 AM:
---------------------------------------------------------------

-Because comments to this issue contain pre-migrate steps, I'm adding post-migrate steps that are needed in standalone:-

{noformat}
/extension=org.jboss.as.web:remove
/extension=org.jboss.as.messaging:remove
/extension=org.jboss.as.jacorb:remove
{noformat}

-This is because the {{:migrate}} operations do not remove the extension (even though they remove the subsystem). And they can't in domain, per http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004287.html (if they could in standalone, I'm not sure).-

The above is no longer true. WFLY-5306 has been resolved in WildFly 10.0.0.CR1, so the extensions are now removed automatically during {{:migrate}} in standalone.


was (Author: lthon):
Because comments to this issue contain pre-migrate steps, I'm adding post-migrate steps that are needed in standalone:

{noformat}
/extension=org.jboss.as.web:remove
/extension=org.jboss.as.messaging:remove
/extension=org.jboss.as.jacorb:remove
{noformat}

This is because the {{:migrate}} operations do not remove the extension (even though they remove the subsystem). And they can't in domain, per http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004287.html (if they could in standalone, I'm not sure).

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 10:16:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 18 Sep 2015 10:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45125.1442585760240@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110451#comment-13110451 ] 

Tom Jenkinson commented on WFLY-5261:
-------------------------------------

Hi,

Please can the report add an "affects version" so its clear if this is for WFLY 9 or WFLY 10 (or both)?

Thanks,
Tom

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:20:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 18 Sep 2015 10:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45138.1442586000227@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110454#comment-13110454 ] 

Ond?ej Chaloupka commented on WFLY-5261:
----------------------------------------

I hit it on WFLY10. I'm not sure about WFLY9.

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:21:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 18 Sep 2015 10:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45142.1442586060188@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5261:
-----------------------------------
    Affects Version/s: 10.0.0.Beta2


> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:29:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 18 Sep 2015 10:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1292) Usage of recover-credential
 for datasource does not take an effect
In-Reply-To: <JIRA.12585386.1442583368000@Atlassian.JIRA>
References: <JIRA.12585386.1442583368000@Atlassian.JIRA>
	<JIRA.12585386.1442583368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585386.1442583368000.45161.1442586540104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated JBJCA-1292:
------------------------------------
    Attachment:     (was: server.log)


> Usage of recover-credential for datasource does not take an effect
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1292
>                 URL: https://issues.jboss.org/browse/JBJCA-1292
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jesper Pedersen
>
> XA datasource configured to use username and password for authentication to database does not consider usage of credential configuration for recovery. When using for example
> {code}
> <security>
>   <user-name>user0</user-name>
>   <password>user0</password>
> </security>
> <recovery>
>   <recover-credential>
>     <user-name>userrecover</user-name>
>     <password>userrecover</password>
>   </recover-credential>
> </recovery>
> {code}
> then recovery for such datasource is trying to be processed with user {{user0}} instead of {{userrecover}} as expected.
> This is a counter part to issue n EAP6 where the same functionality does not work as well. The bz and discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=1021547
> Experiencing error
> {code}
> ERROR [org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon] (EJB default - 2) Cannot start recovering on xares: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
>  at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
>  at org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon.wipeOutTxsInDoubt(CrashHelperCommon.java:72)
>  at org.jboss.as.test.jbossts.crashrec.jpa.JPACrashHelper.wipeOutTxsInDoubt(JPACrashHelper.java:59)
>  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: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.invokeInNoTx(CMTTxInterceptor.java:263)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
>  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.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.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:195)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
>  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:745)
>  at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:31:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 18 Sep 2015 10:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1292) Usage of recover-credential
 for datasource does not take an effect
In-Reply-To: <JIRA.12585386.1442583368000@Atlassian.JIRA>
References: <JIRA.12585386.1442583368000@Atlassian.JIRA>
	<JIRA.12585386.1442583368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585386.1442583368000.45170.1442586660148@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated JBJCA-1292:
------------------------------------
    Attachment: server.log


Replaced with other {{server.log}} file which contains the info. There was missed the logging category {{org.jboss.as.connector}} being set to trace before.

As a side note. I've tried to set the affected version but I couldn't get the version 1.3.0.Final here in jira which should be the version currently in WFLY 10 CR1

> Usage of recover-credential for datasource does not take an effect
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1292
>                 URL: https://issues.jboss.org/browse/JBJCA-1292
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jesper Pedersen
>         Attachments: server.log
>
>
> XA datasource configured to use username and password for authentication to database does not consider usage of credential configuration for recovery. When using for example
> {code}
> <security>
>   <user-name>user0</user-name>
>   <password>user0</password>
> </security>
> <recovery>
>   <recover-credential>
>     <user-name>userrecover</user-name>
>     <password>userrecover</password>
>   </recover-credential>
> </recovery>
> {code}
> then recovery for such datasource is trying to be processed with user {{user0}} instead of {{userrecover}} as expected.
> This is a counter part to issue n EAP6 where the same functionality does not work as well. The bz and discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=1021547
> Experiencing error
> {code}
> ERROR [org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon] (EJB default - 2) Cannot start recovering on xares: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
>  at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
>  at org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon.wipeOutTxsInDoubt(CrashHelperCommon.java:72)
>  at org.jboss.as.test.jbossts.crashrec.jpa.JPACrashHelper.wipeOutTxsInDoubt(JPACrashHelper.java:59)
>  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: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.invokeInNoTx(CMTTxInterceptor.java:263)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
>  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.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.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:195)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
>  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:745)
>  at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:31:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 10:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45173.1442586660199@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110462#comment-13110462 ] 

Tomasz Adamski commented on WFLY-5261:
--------------------------------------

The fix hasn't been merged to 9.

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:37:00 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 18 Sep 2015 10:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1292) Usage of recover-credential
 for datasource does not take an effect
In-Reply-To: <JIRA.12585386.1442583368000@Atlassian.JIRA>
References: <JIRA.12585386.1442583368000@Atlassian.JIRA>
	<JIRA.12585386.1442583368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585386.1442583368000.45185.1442587020231@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110464#comment-13110464 ] 

Jesper Pedersen commented on JBJCA-1292:
----------------------------------------

WildFly/IronJacamar 1.3 is handled by EAP7 JIRAs and BZs.

> Usage of recover-credential for datasource does not take an effect
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1292
>                 URL: https://issues.jboss.org/browse/JBJCA-1292
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jesper Pedersen
>         Attachments: server.log
>
>
> XA datasource configured to use username and password for authentication to database does not consider usage of credential configuration for recovery. When using for example
> {code}
> <security>
>   <user-name>user0</user-name>
>   <password>user0</password>
> </security>
> <recovery>
>   <recover-credential>
>     <user-name>userrecover</user-name>
>     <password>userrecover</password>
>   </recover-credential>
> </recovery>
> {code}
> then recovery for such datasource is trying to be processed with user {{user0}} instead of {{userrecover}} as expected.
> This is a counter part to issue n EAP6 where the same functionality does not work as well. The bz and discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=1021547
> Experiencing error
> {code}
> ERROR [org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon] (EJB default - 2) Cannot start recovering on xares: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
>  at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
>  at org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon.wipeOutTxsInDoubt(CrashHelperCommon.java:72)
>  at org.jboss.as.test.jbossts.crashrec.jpa.JPACrashHelper.wipeOutTxsInDoubt(JPACrashHelper.java:59)
>  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: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.invokeInNoTx(CMTTxInterceptor.java:263)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
>  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.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.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:195)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
>  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:745)
>  at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:37:00 2015
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 18 Sep 2015 10:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1292) Usage of recover-credential
 for datasource does not take an effect
In-Reply-To: <JIRA.12585386.1442583368000@Atlassian.JIRA>
References: <JIRA.12585386.1442583368000@Atlassian.JIRA>
	<JIRA.12585386.1442583368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585386.1442583368000.45188.1442587020310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1292.
----------------------------------
    Resolution: Incomplete Description


Metadata shows crashrec is configured, which the DEBUG statement prints

> Usage of recover-credential for datasource does not take an effect
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1292
>                 URL: https://issues.jboss.org/browse/JBJCA-1292
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jesper Pedersen
>         Attachments: server.log
>
>
> XA datasource configured to use username and password for authentication to database does not consider usage of credential configuration for recovery. When using for example
> {code}
> <security>
>   <user-name>user0</user-name>
>   <password>user0</password>
> </security>
> <recovery>
>   <recover-credential>
>     <user-name>userrecover</user-name>
>     <password>userrecover</password>
>   </recover-credential>
> </recovery>
> {code}
> then recovery for such datasource is trying to be processed with user {{user0}} instead of {{userrecover}} as expected.
> This is a counter part to issue n EAP6 where the same functionality does not work as well. The bz and discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=1021547
> Experiencing error
> {code}
> ERROR [org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon] (EJB default - 2) Cannot start recovering on xares: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
>  at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
>  at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
>  at org.jboss.as.test.jbossts.crashrec.common.CrashHelperCommon.wipeOutTxsInDoubt(CrashHelperCommon.java:72)
>  at org.jboss.as.test.jbossts.crashrec.jpa.JPACrashHelper.wipeOutTxsInDoubt(JPACrashHelper.java:59)
>  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: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.invokeInNoTx(CMTTxInterceptor.java:263)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
>  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
>  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.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.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:195)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
>  at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
>  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:745)
>  at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 10:52:00 2015
From: issues at jboss.org (Ivn Lahav (JIRA))
Date: Fri, 18 Sep 2015 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908300@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.45211.1442587920174@Atlassian.JIRA>

Ivn Lahav created WFLY-5369:
-------------------------------

             Summary: Wildfly doesn't handle @Resource name attribute
                 Key: WFLY-5369
                 URL: https://issues.jboss.org/browse/WFLY-5369
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 9.0.1.Final
            Reporter: Ivn Lahav
            Assignee: Jason Greene


When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.

Here is an example from injecting into Servlet (the same is with injecting into EJBs).
First the part that does work:

{code}
@WebServlet(loadOnStartup=1)
@Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
public class Servlet1 extends HttpServlet {
        @PostConstruct
	public void init0() throws Exception {
		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
	}
}
{code}

So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
Now we  add a field to the above class and use {{@Resource}} injection:

{code}
@Resource(name='db1')
DataSource ds;
{code}

we get the this error:

{code}
Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
	... 5 more
{code}

Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.

This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 10:56:00 2015
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 18 Sep 2015 10:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5365) Upgrade Narayana to
	5.0.7.Final
In-Reply-To: <JIRA.12585370.1442575756000@Atlassian.JIRA>
References: <JIRA.12585370.1442575756000@Atlassian.JIRA>
	<JIRA.12585370.1442575756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585370.1442575756000.45221.1442588160144@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove closed WFLY-5365.
----------------------------------
    Resolution: Rejected


I am rejecting the component upgrade since the associated wildfly issue has been updated to be for 10.0.0.Beta2. We will just make a standard release to cover it. 

> Upgrade Narayana to 5.0.7.Final
> -------------------------------
>
>                 Key: WFLY-5365
>                 URL: https://issues.jboss.org/browse/WFLY-5365
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>    Affects Versions: 9.0.0.CR2
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 9.x.x TBD
>
>
> WFLY-5261 reports that the :reload operation on the server fails because the transaction subsystem does not stop correctly and fails to restart. We have created another release (5.0.7.Final) containing just the fix for https://issues.jboss.org/browse/JBTM-2514



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 11:04:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 11:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45232.1442588640195@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski updated WFLY-5261:
---------------------------------
    Affects Version/s: 9.0.1.Final


> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 11:05:00 2015
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Fri, 18 Sep 2015 11:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.45236.1442588700212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110473#comment-13110473 ] 

Hayk Hovsepyan commented on WFLY-5020:
--------------------------------------

I have checked, it works for ExampleDS.

But still it fails for datasource pointing to MSSQL or any other database.
The error is:
{code}
16:37:25,295 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "remote")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.ejb.remote-transactions-repository",
        "jboss.ejb3.connector"
    ],
    "Services that may be the cause:" => ["jboss.jdbc-driver.sqljdbc4_jar"]
}}
{code}

The steps to reproduce are the same as in description.
Datasource configuration is:
{code}
<datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
<connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
<driver>sqljdbc4.jar</driver>
<security>
  <user-name>username1</user-name>
  <password>password1</password>
</security>
</datasource>
{code}

and the transaction config looks like this
{code}
<jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
{code}

Note: When this datasource is used as regular JTA datasource, there is not a problem to deploy jdbc driver.

> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 11:05:00 2015
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Fri, 18 Sep 2015 11:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.45240.1442588700355@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reopened WFLY-5020:
----------------------------------


> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 11:07:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 11:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45248.1442588820101@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110462#comment-13110462 ] 

Tomasz Adamski edited comment on WFLY-5261 at 9/18/15 11:06 AM:
----------------------------------------------------------------

The fix hasn't been merged to 9 yet.


was (Author: tomekadamski):
The fix hasn't been merged to 9.

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 11:14:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 18 Sep 2015 11:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.45278.1442589240199@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110482#comment-13110482 ] 

Tom Jenkinson commented on WFLY-5020:
-------------------------------------

It looks like this might be an EJB module issue now? What do you think [~maeste]?

> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 11:15:01 2015
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 18 Sep 2015 11:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5365) Upgrade Narayana to
	5.0.7.Final
In-Reply-To: <JIRA.12585370.1442575756000@Atlassian.JIRA>
References: <JIRA.12585370.1442575756000@Atlassian.JIRA>
	<JIRA.12585370.1442575756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585370.1442575756000.45286.1442589301079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove reopened WFLY-5365:
------------------------------------


> Upgrade Narayana to 5.0.7.Final
> -------------------------------
>
>                 Key: WFLY-5365
>                 URL: https://issues.jboss.org/browse/WFLY-5365
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>    Affects Versions: 9.0.0.CR2
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 9.x.x TBD
>
>
> WFLY-5261 reports that the :reload operation on the server fails because the transaction subsystem does not stop correctly and fails to restart. We have created another release (5.0.7.Final) containing just the fix for https://issues.jboss.org/browse/JBTM-2514



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 11:15:01 2015
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 18 Sep 2015 11:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5365) Upgrade Narayana to
	5.0.7.Final
In-Reply-To: <JIRA.12585370.1442575756000@Atlassian.JIRA>
References: <JIRA.12585370.1442575756000@Atlassian.JIRA>
	<JIRA.12585370.1442575756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585370.1442575756000.45290.1442589301144@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated WFLY-5365:
-----------------------------------
    Comment: was deleted

(was: I am rejecting the component upgrade since the associated wildfly issue has been updated to be for 10.0.0.Beta2. We will just make a standard release to cover it. )


> Upgrade Narayana to 5.0.7.Final
> -------------------------------
>
>                 Key: WFLY-5365
>                 URL: https://issues.jboss.org/browse/WFLY-5365
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>    Affects Versions: 9.0.0.CR2
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 9.x.x TBD
>
>
> WFLY-5261 reports that the :reload operation on the server fails because the transaction subsystem does not stop correctly and fails to restart. We have created another release (5.0.7.Final) containing just the fix for https://issues.jboss.org/browse/JBTM-2514



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 11:17:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 18 Sep 2015 11:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45296.1442589420205@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110484#comment-13110484 ] 

Tom Jenkinson commented on WFLY-5261:
-------------------------------------

Thanks for recording that Tomasz. My immediate question is although it affects that stream, do we need to make a WFLY 9 change now as I don't think a release is scheduled? Maybe we could just put it on master and then if a 9.0.2 is announced we can backport at that time? Just a suggestion as there is no 9.0.2 scheduled that I am aware of.

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 11:43:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5167)
 IIOPNamingInContainer*TestCase can not connect to ORB with security manager
In-Reply-To: <JIRA.12582183.1440163708000@Atlassian.JIRA>
References: <JIRA.12582183.1440163708000@Atlassian.JIRA>
	<JIRA.12582183.1440163708000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582183.1440163708000.45380.1442590980309@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110498#comment-13110498 ] 

Tomasz Adamski commented on WFLY-5167:
--------------------------------------

This issue is fixed in openjdk-orb version 8.0.5.Beta1.

> IIOPNamingInContainer*TestCase can not connect to ORB with security manager
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5167
>                 URL: https://issues.jboss.org/browse/WFLY-5167
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.CR1
>            Reporter: Marek Kopeck?
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> *Description of problem:*
> Two tests can not connect to ORB with security manager. Tests run in "basic-integration-default-full.surefire" execution of basic profile.
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerTestCase
> *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=IIOPNamingInContainerDDNameTestCase,IIOPNamingInContainerTestCase
> *Actual results:*
> {noformat}
> avax.naming.NamingException: WFLYIIOP0031: Cannot connect to ORB
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2200)
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2221)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:223)
> 	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 org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:353)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingCorbanameUrl(CNCtx.java:335)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingUrl(CNCtx.java:268)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:233)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
> 	at org.wildfly.iiop.openjdk.naming.jndi.WrapperInitialContext.lookup(WrapperInitialContext.java:72)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase.testIIOPNamingInvocationWithDDOverride(IIOPNamingInContainerDDNameTestCase.java:55)
> {noformat}
> *Expected results:*
> No errors on output



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 11:43:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5167)
 IIOPNamingInContainer*TestCase can not connect to ORB with security manager
In-Reply-To: <JIRA.12582183.1440163708000@Atlassian.JIRA>
References: <JIRA.12582183.1440163708000@Atlassian.JIRA>
	<JIRA.12582183.1440163708000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582183.1440163708000.45384.1442590980399@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski resolved WFLY-5167.
----------------------------------
    Fix Version/s: 10.0.0.CR2
       Resolution: Done


> IIOPNamingInContainer*TestCase can not connect to ORB with security manager
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5167
>                 URL: https://issues.jboss.org/browse/WFLY-5167
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.CR1
>            Reporter: Marek Kopeck?
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> *Description of problem:*
> Two tests can not connect to ORB with security manager. Tests run in "basic-integration-default-full.surefire" execution of basic profile.
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerTestCase
> *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=IIOPNamingInContainerDDNameTestCase,IIOPNamingInContainerTestCase
> *Actual results:*
> {noformat}
> avax.naming.NamingException: WFLYIIOP0031: Cannot connect to ORB
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2200)
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2221)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:223)
> 	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 org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:353)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingCorbanameUrl(CNCtx.java:335)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingUrl(CNCtx.java:268)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:233)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
> 	at org.wildfly.iiop.openjdk.naming.jndi.WrapperInitialContext.lookup(WrapperInitialContext.java:72)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase.testIIOPNamingInvocationWithDDOverride(IIOPNamingInContainerDDNameTestCase.java:55)
> {noformat}
> *Expected results:*
> No errors on output



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 11:43:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5167)
 IIOPNamingInContainer*TestCase can not connect to ORB with security manager
In-Reply-To: <JIRA.12582183.1440163708000@Atlassian.JIRA>
References: <JIRA.12582183.1440163708000@Atlassian.JIRA>
	<JIRA.12582183.1440163708000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582183.1440163708000.45388.1442590980632@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski updated WFLY-5167:
---------------------------------
    Affects Version/s: 10.0.0.CR1


> IIOPNamingInContainer*TestCase can not connect to ORB with security manager
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5167
>                 URL: https://issues.jboss.org/browse/WFLY-5167
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.CR1
>            Reporter: Marek Kopeck?
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> *Description of problem:*
> Two tests can not connect to ORB with security manager. Tests run in "basic-integration-default-full.surefire" execution of basic profile.
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerTestCase
> *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=IIOPNamingInContainerDDNameTestCase,IIOPNamingInContainerTestCase
> *Actual results:*
> {noformat}
> avax.naming.NamingException: WFLYIIOP0031: Cannot connect to ORB
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2200)
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2221)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:223)
> 	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 org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:353)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingCorbanameUrl(CNCtx.java:335)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingUrl(CNCtx.java:268)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:233)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
> 	at org.wildfly.iiop.openjdk.naming.jndi.WrapperInitialContext.lookup(WrapperInitialContext.java:72)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase.testIIOPNamingInvocationWithDDOverride(IIOPNamingInContainerDDNameTestCase.java:55)
> {noformat}
> *Expected results:*
> No errors on output



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 11:58:00 2015
From: issues at jboss.org (Jan Stourac (JIRA))
Date: Fri, 18 Sep 2015 11:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5364) HTTP2 stream ID is not
 checked for some frame types
In-Reply-To: <JIRA.12585368.1442575351000@Atlassian.JIRA>
References: <JIRA.12585368.1442575351000@Atlassian.JIRA>
	<JIRA.12585368.1442575351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585368.1442575351000.45416.1442591880136@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Stourac updated WFLY-5364:
------------------------------
    Description: 
According to [RFC7540|https://tools.ietf.org/html/rfc7540] frame types DATA, PRIORITY and HEADERS are associated with particular data stream, therefore if its stream id is 0 this should be processed as PROTOCOL_ERROR.

Similarly frames of types GOAWAY and SETTINGS must not be associated with particular stream id other than 0, if so then PROTOCOL_ERROR should be raised.

With current implementation this requirement is not checked causing discrepation against RFC specification.

  was:
According to [RFC7540|https://tools.ietf.org/html/rfc7540] frame types DATA and HEADERS are associated with particular data stream, therefore if its stream id is 0 this should be processed as PROTOCOL_ERROR.

Similarly frames of types GOAWAY and SETTINGS must not be associated with particular stream id other than 0, if so then PROTOCOL_ERROR should be raised.

With current implementation this requirement is not checked causing discrepation against RFC specification.



> HTTP2 stream ID is not checked for some frame types
> ---------------------------------------------------
>
>                 Key: WFLY-5364
>                 URL: https://issues.jboss.org/browse/WFLY-5364
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>
> According to [RFC7540|https://tools.ietf.org/html/rfc7540] frame types DATA, PRIORITY and HEADERS are associated with particular data stream, therefore if its stream id is 0 this should be processed as PROTOCOL_ERROR.
> Similarly frames of types GOAWAY and SETTINGS must not be associated with particular stream id other than 0, if so then PROTOCOL_ERROR should be raised.
> With current implementation this requirement is not checked causing discrepation against RFC specification.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:04:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 18 Sep 2015 12:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215242@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.45433.1442592240053@Atlassian.JIRA>

Mario Fusco created DROOLS-924:
----------------------------------

             Summary: EventFactHandles are not deserialized correctly
                 Key: DROOLS-924
                 URL: https://issues.jboss.org/browse/DROOLS-924
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:12:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 18 Sep 2015 12:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.45446.1442592720064@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-924.
--------------------------------
    Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/59d791076204d28ed370bf83b7f21e9864b0a701 and https://github.com/droolsjbpm/jbpm/commit/c6fd866c5

> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:24:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 18 Sep 2015 12:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-800) Support file in management
	operation
In-Reply-To: <JIRA.12577572.1436449664000@Atlassian.JIRA>
References: <JIRA.12577572.1436449664000@Atlassian.JIRA>
	<JIRA.12577572.1436449664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577572.1436449664000.45470.1442593440311@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110507#comment-13110507 ] 

Alexey Loubyansky commented on WFCORE-800:
------------------------------------------

I just wanted to mention in some way related features supported in the CLI.

WFCORE-74 introduced optional boolean filesystem-path attribute to the description of resource attributes and operation parameters. Which indicates that the value of the attribute/parameter is a filesystem  path (the type might still be STRING).

WFCORE-217 - for any operation who has a parameter type of ModelType.BYTES, treat the user-supplied value as a file path from which to retrieve those bytes.

> Support file in management operation
> ------------------------------------
>
>                 Key: WFCORE-800
>                 URL: https://issues.jboss.org/browse/WFCORE-800
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Alpha6
>            Reporter: Jeff Mesnil
>            Assignee: Alexey Loubyansky
>              Labels: affects_elytron
>
> Working on WFLY-4683, I want to add 2 management operations :export-journal and :import-journal that export/import the journal from the messaging-activemq server resource.
> The :export-journal operation is similar to the :take-snapshot operation and it is acceptable that the dumped file (created internally by Artemis) is stored on the server-side in a well-know location
> However, I'd like to pass such a file to the :import-journal (specified by a dump attribute) so that the admin does not need to copy the dumped file to the server's host (or many hosts in domain mode) before calling the :import-journal operation.
> Currently, this is not doable since we can not add a stream to a management operation *from the CLI*. Instead, I have to implement a global command that will execute the client code to create the management operation, read the file and attach it to the operation as a stream.
> Ideally, I would like to specify that my :import-journal takes a dump attribute with the ModelType.FILE (or .URL ?) so that our management clients (both CLI and Web) know that they must attach the stream of the file to the management operation.
> This RFE is to simplify this use case and make it possible to use directly the CLI (and Web) console to upload files without having to create a dedicated client command for that.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:39:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 18 Sep 2015 12:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-966) In domain mode non existing
 subhandler is saved to attributes.
In-Reply-To: <JIRA.12583440.1441114363000@Atlassian.JIRA>
References: <JIRA.12583440.1441114363000@Atlassian.JIRA>
	<JIRA.12583440.1441114363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583440.1441114363000.45510.1442594340156@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110510#comment-13110510 ] 

James Perkins commented on WFCORE-966:
--------------------------------------

The issue is the profile isn't running and therefore runtime stage steps are not run. In some cases validation only runs at runtime since it's the best place to validate whether or not something like a handler exists. Some thought would have to go into the best way to validate this. It won't allow the profile to actually boot as it would fail in the runtime stages.

I'll leave this unscheduled for now as it's likely fixable, just needs to be well thought out.

> In domain mode non existing subhandler is saved to attributes.
> --------------------------------------------------------------
>
>                 Key: WFCORE-966
>                 URL: https://issues.jboss.org/browse/WFCORE-966
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>         Environment: Running unsecured EAP 7.0.0 DR9 version in domain mode.
>            Reporter: Patrik Cyprian
>            Assignee: James Perkins
>
> When you in domain mode in created async handler add non existing sub handler to attributes it is successfully saved. In standalone mode it is not possible (subhandler is not saved - saving operation failed).
> 1.Run EAP in domain mode (default profile)
> 2.Create async handler
> 3.Try to add non existing subhandler to async handler attributes
> 4.Try the same in standalone mode with standalone-full-ha profile



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:41:01 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 18 Sep 2015 12:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-939) Embedded host controller
 should set launch type attribute to EMBEDDED
In-Reply-To: <JIRA.12583251.1441022081000@Atlassian.JIRA>
References: <JIRA.12583251.1441022081000@Atlassian.JIRA>
	<JIRA.12583251.1441022081000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583251.1441022081000.45515.1442594461294@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFCORE-939:
------------------------------------

    Assignee: James Perkins  (was: Ken Wills)


> Embedded host controller should set launch type attribute to EMBEDDED
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-939
>                 URL: https://issues.jboss.org/browse/WFCORE-939
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: James Perkins
>             Fix For: 2.0.0.CR2
>
>
> *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded. 
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
>     /** The manner in which a server can be launched */
>     public static enum LaunchType {
>         /** Launched by a Host Controller in a managed domain */
>         DOMAIN(ProcessType.DOMAIN_SERVER),
>         /** Launched from the command line */
>         STANDALONE(ProcessType.STANDALONE_SERVER),
>         /** Launched by another process in which the server is embedded */
>         EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type              STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type              DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server 
> launch-type              EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type              DOMAIN
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:45:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Sep 2015 12:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.45522.1442594700136@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-924:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1264525
        Bugzilla Update: Perform


> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:46:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Sep 2015 12:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.45524.1442594760130@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110512#comment-13110512 ] 

RH Bugzilla Integration commented on DROOLS-924:
------------------------------------------------

Gary Hu <ghu at redhat.com> changed the Status of [bug 1264525|https://bugzilla.redhat.com/show_bug.cgi?id=1264525] from NEW to ASSIGNED

> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:48:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Sep 2015 12:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.45529.1442594880305@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110514#comment-13110514 ] 

RH Bugzilla Integration commented on DROOLS-924:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1264525|https://bugzilla.redhat.com/show_bug.cgi?id=1264525] from ASSIGNED to MODIFIED

> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:49:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 18 Sep 2015 12:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-800) Support file in management
	operation
In-Reply-To: <JIRA.12577572.1436449664000@Atlassian.JIRA>
References: <JIRA.12577572.1436449664000@Atlassian.JIRA>
	<JIRA.12577572.1436449664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577572.1436449664000.45543.1442594940172@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110515#comment-13110515 ] 

Alexey Loubyansky commented on WFCORE-800:
------------------------------------------

As an alternative, we could consider the following: if there is an int parameter and it has filesystem-path=true in its description, we could treated it as a string parameter with a filesystem path value for the user but turn it into a stream when we send the request.

> Support file in management operation
> ------------------------------------
>
>                 Key: WFCORE-800
>                 URL: https://issues.jboss.org/browse/WFCORE-800
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Alpha6
>            Reporter: Jeff Mesnil
>            Assignee: Alexey Loubyansky
>              Labels: affects_elytron
>
> Working on WFLY-4683, I want to add 2 management operations :export-journal and :import-journal that export/import the journal from the messaging-activemq server resource.
> The :export-journal operation is similar to the :take-snapshot operation and it is acceptable that the dumped file (created internally by Artemis) is stored on the server-side in a well-know location
> However, I'd like to pass such a file to the :import-journal (specified by a dump attribute) so that the admin does not need to copy the dumped file to the server's host (or many hosts in domain mode) before calling the :import-journal operation.
> Currently, this is not doable since we can not add a stream to a management operation *from the CLI*. Instead, I have to implement a global command that will execute the client code to create the management operation, read the file and attach it to the operation as a stream.
> Ideally, I would like to specify that my :import-journal takes a dump attribute with the ModelType.FILE (or .URL ?) so that our management clients (both CLI and Web) know that they must attach the stream of the file to the management operation.
> This RFE is to simplify this use case and make it possible to use directly the CLI (and Web) console to upload files without having to create a dedicated client command for that.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 12:58:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 18 Sep 2015 12:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-643) On Windows,
 setting the JAVA_OPTS variable is not
In-Reply-To: <JIRA.12568519.1429117668000@Atlassian.JIRA>
References: <JIRA.12568519.1429117668000@Atlassian.JIRA>
	<JIRA.12568519.1429117668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568519.1429117668000.45583.1442595480169@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky reassigned WFCORE-643:
----------------------------------------

    Assignee: Tomaz Cerar  (was: Alexey Loubyansky)


> On Windows, setting the JAVA_OPTS variable is not
> -------------------------------------------------
>
>                 Key: WFCORE-643
>                 URL: https://issues.jboss.org/browse/WFCORE-643
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.0.Beta4
>         Environment: Windows 7 x64, JRE was bundled with JDK 8 u40 x64.
> Hardware specs:
> CPU: Intel Core i7-3720QM CPU @ 2.60 GHz
> RAM: 16.0 GB
> GPU: NVIDIA Quadro K1000M
> Others upon request.
>            Reporter: Tom Kelley
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> {warn} This issue was copy/pasted from a github issue [here|https://github.com/wildfly/wildfly/issues/7352]. I apologize for 1) the issue duplication, 2) the length of the issue, 3) any poor communication that the transcription caused. {warn}
> My company uses JBoss AS, and I have a copy on my local machine. In setting it up, I wrote a small script that lives in the bin directory and looks something like this:
> {code}
> @rem Delete current log file
> del /F /Q ..\standalone\log\server.log
> @rem Set Java Opts because I want to
> set JAVA_OPTS="-XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,server=y,suspend=n"
> @rem Set the new Java Home
> set JAVA_HOME=C:\bin\java\jdk8_u40_64\jre
> @rem Run Jboss
> standalone.bat -c=standalone-full.xml --debug
> {code}
> I noticed when I was starting the server that the JAVA_OPTS in the debug text were not what I was passing in. I figured I could get to the bottom of what was going on, so I started digging in. My investigation led me to standalone.conf.bat, which looks like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x%JAVA_OPTS%" == "x" (
>   echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
>   goto JAVA_OPTS_SET
> )
> {code}
> This is very interesting. This snippet of code appears to be a bug. As someone who has worked with batch files, I believe that the correct code should look like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x"%JAVA_OPTS% == "x" (
>   echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
>   goto JAVA_OPTS_SET
> )
> {code}
> You must be thinking, "if you know how to do this, why don't you just make the change yourself? It seems trivial." I would, but I'm not able to find the batch file in the source tree. It appears (to me) that the batch file is generated, and I don't know what to start looking for in order to fix this issue on my own.
> As such, I've created a test batch file (meant to be run on Windows) that I've attached to this Issue. When the issue is fixed, it should output something like this:
> {code}
> Calling "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT\bin\standalone.conf.bat"
> "JAVA_OPTS already set in environment; overriding default settings with values: "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> Setting JAVA property to "C:\bin\java\jdk8_u40_64\jre\bin\java"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT"
>   JAVA: "C:\bin\java\jdk8_u40_64\jre\bin\java"
>   JAVA_OPTS: "-Dprogram.name=standalone.bat "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> ===============================================================================
> Error: Could not find or load main class Look at me. LOOK AT ME. I am the JAVA_OPTS now.
> {code}
> The batch file can be acquired [here|https://cloud.githubusercontent.com/assets/2186874/7147925/844bc00c-e2b3-11e4-8320-571fb732bc9f.jpg], just save the link as a batch file, or save it and change the extension (the same way that we get around email filters that don't let us send *.exe's). The way that I ran this was to put the batch file at the root of the Wildfly directory and then call it using window's CMD. The test case does several things:
> 1. Maven clean
> 2. Call build.bat
> 3. Set a JAVA_OPTS system variable
> 4. Call the standalone.bat in the new version of Wildfly that was created in step 2 (as long as the target dir is still wildfly-9.0.0.CR1-SNAPSHOT).
> I would love to take lead on fixing this, but I'm not sure where to start. If someone could give me a point in the right direction, that would be great. Thanks.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 13:04:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 18 Sep 2015 13:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.45593.1442595840142@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-988:
------------------------------------
    Fix Version/s: 2.0.0.CR2


> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 13:06:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Fri, 18 Sep 2015 13:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-949) Removing http-interface
 autocompletes but fails
In-Reply-To: <JIRA.12583637.1441256915000@Atlassian.JIRA>
References: <JIRA.12583637.1441256915000@Atlassian.JIRA>
	<JIRA.12583637.1441256915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583637.1441256915000.45598.1442595960255@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-949:
-------------------------------------
    Fix Version/s: 2.0.0.CR2


> Removing http-interface autocompletes but fails
> -----------------------------------------------
>
>                 Key: WFCORE-949
>                 URL: https://issues.jboss.org/browse/WFCORE-949
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Petr Kremensky
>            Assignee: ehsavoie Hugonnet
>              Labels: affects_elytron
>             Fix For: 2.0.0.CR2
>
>
> Executing /core-service=management/management-interface=http-interface:remove() autocompletes but does not succeed. 
> This is a link to a paste of the server stacktrace.
> http://pastebin.test.redhat.com/310136



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 13:38:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 18 Sep 2015 13:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-919) Triggering an incremental
 compilation from inside a consequence causes a deadlock
In-Reply-To: <JIRA.12585260.1442500892000@Atlassian.JIRA>
References: <JIRA.12585260.1442500892000@Atlassian.JIRA>
	<JIRA.12585260.1442500892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585260.1442500892000.45636.1442597880075@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco closed DROOLS-919.
------------------------------
    Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/ef0da32d7

> Triggering an incremental compilation from inside a consequence causes a deadlock
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-919
>                 URL: https://issues.jboss.org/browse/DROOLS-919
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> Triggering an incremental compilation (i.e. calling kieContainer.updateToVersion) from inside a rule consequence causes a deadlock because it attempts to update the read lock on the kbase acquired when invoking ksession.fireAllRules() to a write lock.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 13:42:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 18 Sep 2015 13:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.45643.1442598120151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110528#comment-13110528 ] 

Brian Stansberry commented on WFCORE-988:
-----------------------------------------

The issue here (as James debugged) is the domain rollout stuff is run in threads unassociated with the OperationContext, but the transformation work those threads do is using a ref to the OC to read the model.

The OC should not be being handed out to other threads. The reads that need to happen for transformation should occur before the rollout tasks get started, with the result of the reads provided to the tasks, not the OC itself.

> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 14:05:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 14:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-910) Add an Undertow SPNEGO
 authentication mechanism
In-Reply-To: <JIRA.12584412.1441807528000@Atlassian.JIRA>
References: <JIRA.12584412.1441807528000@Atlassian.JIRA>
	<JIRA.12584412.1441807528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584412.1441807528000.45681.1442599500097@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110535#comment-13110535 ] 

Darran Lofthouse commented on SECURITY-910:
-------------------------------------------

TODO 
# Remove the JBoss Web specific classes and references to JBoss Web in the poms.
# Add a handler to associate any delegated credential with the Thread handling the request.


> Add an Undertow SPNEGO authentication mechanism
> -----------------------------------------------
>
>                 Key: SECURITY-910
>                 URL: https://issues.jboss.org/browse/SECURITY-910
>             Project: PicketBox 
>          Issue Type: Feature Request
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_CR1
>
>
> Undertow does contain an SPNEGO authentication mechanism however this is not compatible with the LoginModule approach of JBoss Negotiation so an alternative mechanism is required here.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 14:07:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Sep 2015 14:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Support for SPNEGO
 authentication for deployed web applications
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.45711.1442599620856@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110538#comment-13110538 ] 

Darran Lofthouse commented on WFLY-2553:
----------------------------------------

TODO 
# Add a negotiation delegation filter 
# Upgrade to the .Final release


> Support for SPNEGO authentication for deployed web applications
> ---------------------------------------------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 14:23:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Fri, 18 Sep 2015 14:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.45728.1442600580143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-756:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR2)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 3.0.0.Alpha1
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 14:28:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 18 Sep 2015 14:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5370) NPE during undeploy due to
 asynchronous cache listeners
In-Reply-To: <JIRA.12585412.1442600839000@Atlassian.JIRA>
References: <JIRA.12585412.1442600839000@Atlassian.JIRA>
	<JIRA.12585412.1442600839806@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585412.1442600839000.45731.1442600880133@Atlassian.JIRA>

Paul Ferraro created WFLY-5370:
----------------------------------

             Summary: NPE during undeploy due to asynchronous cache listeners
                 Key: WFLY-5370
                 URL: https://issues.jboss.org/browse/WFLY-5370
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


This issue lies outside the bounds of traditional clean shutdown, since the initiating events are driven by activity by other nodes, or asynchronous events driven by local node activity.  Essentially, we need a simple mechanism for blocking shutdown until active listeners complete.
{noformat}
[JBossINF] [0m[31m04:43:50,274 ERROR [org.infinispan.remoting.rpc.RpcManagerImpl] (transport-thread--p7-t21) ISPN000073: Unexpected error while replicating: java.lang.NullPointerException
[JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:568)
[JBossINF] 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:170)
[JBossINF] 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:212)
[JBossINF] 	at org.infinispan.transaction.impl.AbstractEnlistmentAdapter.removeTransactionInfoRemotely(AbstractEnlistmentAdapter.java:93)
[JBossINF] 	at org.infinispan.transaction.impl.AbstractEnlistmentAdapter.releaseLocksForCompletedTransaction(AbstractEnlistmentAdapter.java:83)
[JBossINF] 	at org.infinispan.transaction.xa.TransactionXaAdapter.forgetSuccessfullyCompletedTransaction(TransactionXaAdapter.java:230)
[JBossINF] 	at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:116)
[JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:371)
[JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:417)
[JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:301)
[JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:104)
[JBossINF] 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
[JBossINF] 	at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48)
[JBossINF] 	at org.wildfly.clustering.server.registry.CacheRegistry.topologyChanged(CacheRegistry.java:154)
[JBossINF] 	at sun.reflect.GeneratedMethodAccessor25.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:21)
[JBossINF] 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
[JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1185)
[JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1143)
[JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1108)
[JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:557)
[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.resetLocalTopologyBeforeRebalance(LocalTopologyManagerImpl.java:328)
[JBossINF] 	at org.infinispan.topology.LocalTopologyManagerImpl.doHandleRebalance(LocalTopologyManagerImpl.java:408)
[JBossINF] 	at org.infinispan.topology.LocalTopologyManagerImpl$3.run(LocalTopologyManagerImpl.java:377)
[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)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 14:30:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Sep 2015 14:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.45737.1442601000211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-924:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1264525, https://bugzilla.redhat.com/show_bug.cgi?id=1264541  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1264525)


> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 14:57:00 2015
From: issues at jboss.org (Rich DiCroce (JIRA))
Date: Fri, 18 Sep 2015 14:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5371) Stock configuration for
 ActiveMQ should specify a JGroups channel instead of a stack
In-Reply-To: <JIRA.12585414.1442602571000@Atlassian.JIRA>
References: <JIRA.12585414.1442602571000@Atlassian.JIRA>
	<JIRA.12585414.1442602571365@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585414.1442602571000.45826.1442602620188@Atlassian.JIRA>

Rich DiCroce created WFLY-5371:
----------------------------------

             Summary: Stock configuration for ActiveMQ should specify a JGroups channel instead of a stack
                 Key: WFLY-5371
                 URL: https://issues.jboss.org/browse/WFLY-5371
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 10.0.0.CR1
            Reporter: Rich DiCroce
            Assignee: Jeff Mesnil


The stock configuration specifies jgroups-stack="udp" in the messaging-activemq subsystem. This appears to cause a second instance of that stack to be created if other subsystems (e.g. Infinispan) are also using it. That second instance appears to cause WFLY-4971.

WildFly still seems happy if I change the jgroups-stack to "ee" (to use the ee channel) or to a fork off the ee channel. The stock configuration should do the same thing to fix WFLY-4971.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 15:10:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 15:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45849.1442603400292@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110554#comment-13110554 ] 

Tomasz Adamski commented on WFLY-5261:
--------------------------------------

I believe we can wait on 9.0.2 then.

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 15:11:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 18 Sep 2015 15:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.45853.1442603460131@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110554#comment-13110554 ] 

Tomasz Adamski edited comment on WFLY-5261 at 9/18/15 3:10 PM:
---------------------------------------------------------------

I believe we can wait and merge it only after new version is announced.


was (Author: tomekadamski):
I believe we can wait on 9.0.2 then.

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 15:28:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 18 Sep 2015 15:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.45883.1442604480207@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110559#comment-13110559 ] 

Jason Greene commented on WFLY-5369:
------------------------------------

Hello Ivn,

The name attribute of @Resource specifies the destination of the binding to create, as opposed to lookup, which specifies the source to retrieve. These two definitions conflict because they are both trying to define java:comp/env/db1.  The class declaration defines it to point to ?java:jboss/datasources/ExampleDS?, wheras the field declaration defines it to point to the default ?java:comp/DefaultDataSource?.  

The right way to do this, is to change the field declaration to be:

```java
@Resource(lookup=?java:comp/db1?)
DataSource ds;
```

This field will then correctly reference the binding created by the class defined by @Resource

> Wildfly doesn't handle @Resource name attribute
> -----------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 15:29:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 18 Sep 2015 15:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.45888.1442604540291@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110559#comment-13110559 ] 

Jason Greene edited comment on WFLY-5369 at 9/18/15 3:28 PM:
-------------------------------------------------------------

Hello Ivn,

The name attribute of @Resource specifies the destination of the binding to create, as opposed to lookup, which specifies the source to retrieve. These two definitions conflict because they are both trying to define java:comp/env/db1.  The class declaration defines it to point to ?java:jboss/datasources/ExampleDS?, wheras the field declaration defines it to point to the default ?java:comp/DefaultDataSource?.  

The right way to do this, is to change the field declaration to be:

{code}
@Resource(lookup=?java:comp/db1?)
DataSource ds;
{code}

This field will then correctly reference the binding created by the class defined by @Resource


was (Author: jason.greene):
Hello Ivn,

The name attribute of @Resource specifies the destination of the binding to create, as opposed to lookup, which specifies the source to retrieve. These two definitions conflict because they are both trying to define java:comp/env/db1.  The class declaration defines it to point to ?java:jboss/datasources/ExampleDS?, wheras the field declaration defines it to point to the default ?java:comp/DefaultDataSource?.  

The right way to do this, is to change the field declaration to be:

```java
@Resource(lookup=?java:comp/db1?)
DataSource ds;
```

This field will then correctly reference the binding created by the class defined by @Resource

> Wildfly doesn't handle @Resource name attribute
> -----------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 15:29:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 18 Sep 2015 15:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.45892.1442604540372@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110559#comment-13110559 ] 

Jason Greene edited comment on WFLY-5369 at 9/18/15 3:28 PM:
-------------------------------------------------------------

Hello Ivn,

The name attribute of @Resource specifies the destination of the binding to create, as opposed to lookup, which specifies the source to retrieve. These two definitions conflict because they are both trying to define java:comp/env/db1.  The class declaration defines it to point to ?java:jboss/datasources/ExampleDS?, wheras the field declaration defines it to point to the default ?java:comp/DefaultDataSource?.  

The right way to do this, is to change the field declaration to be:

{code}
@Resource(lookup=?java:comp/env/db1?)
DataSource ds;
{code}

This field will then correctly reference the binding created by the class defined by @Resource


was (Author: jason.greene):
Hello Ivn,

The name attribute of @Resource specifies the destination of the binding to create, as opposed to lookup, which specifies the source to retrieve. These two definitions conflict because they are both trying to define java:comp/env/db1.  The class declaration defines it to point to ?java:jboss/datasources/ExampleDS?, wheras the field declaration defines it to point to the default ?java:comp/DefaultDataSource?.  

The right way to do this, is to change the field declaration to be:

{code}
@Resource(lookup=?java:comp/db1?)
DataSource ds;
{code}

This field will then correctly reference the binding created by the class defined by @Resource

> Wildfly doesn't handle @Resource name attribute
> -----------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 18 15:29:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 18 Sep 2015 15:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.45896.1442604540446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene resolved WFLY-5369.
--------------------------------
    Fix Version/s: No Release
       Resolution: Rejected


> Wildfly doesn't handle @Resource name attribute
> -----------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 15:32:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Sep 2015 15:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
In-Reply-To: <JIRA.12562785.1423556555000@Atlassian.JIRA>
References: <JIRA.12562785.1423556555000@Atlassian.JIRA>
	<JIRA.12562785.1423556555000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562785.1423556555000.45899.1442604720374@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated REMJMX-94:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1191002, https://bugzilla.redhat.com/show_bug.cgi?id=1264555  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1191002)


> Memory leak in remoting-jmx
> ---------------------------
>
>                 Key: REMJMX-94
>                 URL: https://issues.jboss.org/browse/REMJMX-94
>             Project: Remoting JMX
>          Issue Type: Bug
>    Affects Versions: 1.1.3.Final
>            Reporter: Libor Zoubek
>            Assignee: Darran Lofthouse
>              Labels: memory_leak
>             Fix For: 2.0.2.CR1
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org/jboss/remotingjmx/memleak/test/Main.java
> I am not sure if memleak is in remoting-jmx or some other underlying stuff. 
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 17:06:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Fri, 18 Sep 2015 17:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.46093.1442610360117@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110577#comment-13110577 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

Paul, hasn't this been the setting for JGoups?  If this has changed, then what the updated method?  Where is this documented?

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 18:14:00 2015
From: issues at jboss.org (Ivn Lahav (JIRA))
Date: Fri, 18 Sep 2015 18:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute for DataSource type
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.46144.1442614440163@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivn Lahav updated WFLY-5369:
----------------------------
    Summary: Wildfly doesn't handle @Resource name attribute for DataSource type  (was: Wildfly doesn't handle @Resource name attribute)


> Wildfly doesn't handle @Resource name attribute for DataSource type
> -------------------------------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 18:24:00 2015
From: issues at jboss.org (Ivn Lahav (JIRA))
Date: Fri, 18 Sep 2015 18:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute for DataSource type
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.46149.1442615040077@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110587#comment-13110587 ] 

Ivn Lahav commented on WFLY-5369:
---------------------------------

Hi Jason,

The name attribute of the @Resource does represent the destination of the binding to create but only when when combined with the actual instruction (lookup or mappedName) to create such binding. When used without lookup or mappedName it represents the source in ENC to inject from.

When using lookup instead of name for injection, it will actually create additional binding, with a default name derived from the class and field names. In your example above, it will inject the correct value but will create a binding as can be verified by:

{code}
System.out.println(InitialContext.doLookup("java:comp/env/pkg.Servlet2/ds"));
{code}

I verified using name for injection on Weblogic and on TomEE and it works properly. In fact, it also works in Wildfly as well, as long as the type is not DataSource. 
I tried the original example from above with JMS Queue and also with a simple Integer, and it works without any issue. Also even with DataSource, by changing the type of the field from DataSource to Object it starts working. So there is some bug with DataSource injection.

By the way, as one of the examples that shows resource injection by name, see
  https://docs.oracle.com/javaee/6/tutorial/doc/bncjk.html


> Wildfly doesn't handle @Resource name attribute for DataSource type
> -------------------------------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 18 23:12:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 18 Sep 2015 23:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-989) Premature registration of
 reconnecting server
In-Reply-To: <JIRA.12585427.1442632267000@Atlassian.JIRA>
References: <JIRA.12585427.1442632267000@Atlassian.JIRA>
	<JIRA.12585427.1442632267249@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585427.1442632267000.46188.1442632320082@Atlassian.JIRA>

Brian Stansberry created WFCORE-989:
---------------------------------------

             Summary: Premature registration of reconnecting server
                 Key: WFCORE-989
                 URL: https://issues.jboss.org/browse/WFCORE-989
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.CR1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR2


ServerInventoryImpl.reconnectServer is registering the ProxyController for the reconnecting server with the DomainModelControllerService. The problem is that ProxyController is not yet in a state where it can forward requests to the server. That won't happen until the server calls back with a DomainServerProtocol.SERVER_RECONNECT_REQUEST and the ServerToHostProtocolHandler.ServerReconnectRequestHandler handles it. The effect is if a request for the server comes in during this window, it will fail. If that request is part of a domain operation rollout (because during the window the HC regarded the server as 'live' and instructed the DC to send rollout ops to it), then the domain rollout will be affected. This happened in the testsuite failure I just saw. Most significant logging is as follows:

{code}
2015-09-18 17:59:32,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" (Host Controller) started in 93ms - Started 48 of 51 services (15 services are lazy, passive or on-demand)
2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-16) Initialized for 1849055188
2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-14) WFLYHC0021: Server [Server:main-three] connected using connection [Channel ID 08aa200b (inbound) of Remoting connection 27e3d90d to /127.0.0.1:49272]
2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-15) WFLYHC0021: Server [Server:other-two] connected using connection [Channel ID 02bd2646 (inbound) of Remoting connection 64a8b7f2 to /127.0.0.1:49273]
2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) Initialized for 1849055188
2015-09-18 17:59:32,252 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) sending prepared response for 1849055188  --- interrupted: false
2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 1933145457
2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 481103151
2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) Initialized for 1933145457
2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) Initialized for 481103151
2015-09-18 17:59:32,255 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) sending pre-prepare failed response for 1933145457  --- interrupted: false
2015-09-18 17:59:32,256 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) sending pre-prepare failed response for 481103151  --- interrupted: false
{code}

The HC completes boot. Then servers main-three and other-two register. The HC sends a prepared response to a request. This is the host rollout request to the slave from the DC with the response being the ops to invoke on the servers. The HC reports sending a "pre-prepare failed response" to two requests. These are the requests the DC has asked it to proxy to the servers.

The result of all this for the client is the following failure of a management op:

{code}
Failed operation:
{
    "operation" => "add",
    "address" => [("extension" => "org.jboss.as.test.hc.extension")]
}
Response:
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
        "main-server-group" => {"host" => {"slave" => {"main-three" => "WFLYHC0153: Channel closed"}}},
        "other-server-group" => {"host" => {"slave" => {"other-two" => "WFLYHC0153: Channel closed"}}}
    }}},
    "rolled-back" => true,
    "server-groups" => {
        "main-server-group" => {"host" => {
            "master" => {"main-one" => {"response" => {
                "outcome" => "failed",
                "result" => [("HC" => "1.1.1")],
                "rolled-back" => true
            }}},
            "slave" => {"main-three" => {"response" => {
                "outcome" => "failed",
                "result" => undefined,
                "failure-description" => "WFLYHC0153: Channel closed",
                "rolled-back" => true
            }}}
        }},
        "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => {
            "outcome" => "failed",
            "result" => undefined,
            "failure-description" => "WFLYHC0153: Channel closed",
            "rolled-back" => true
        }}}}}
    }
}
{code}

The "WFLYHC0153: Channel closed" failure is what is produced when an attempt is made to invoke on a disconnected proxy controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 19 00:01:02 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Sat, 19 Sep 2015 00:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute for DataSource type
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.46192.1442635262064@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110594#comment-13110594 ] 

Jason Greene commented on WFLY-5369:
------------------------------------

Hi Ivn,

If you declare a @Resource without a lookup (or mappedName), then the JNDI name it resolves is either defined by a deployment descriptor or its set to one of the EE7 defined default resource. So in this case its ?java:comp/DefaultDataSource? per EE 5.1.9. The spec also requires that duplicate @Resource declarations (specify the same name in the same namespace) by validated to be identical and error if not (EE 5.2.2 "If all attributes of each declaration of a shared environment entry are not identical, this must be reported as a deployment error to the Deployer. "). This is the case since they effectively specify different names. Now technically with our stock config those names both resolve to the same underlying resource, so we could be smarter and specially handle that case, but if the default data source does not match the resource in the class annotation the error would then still occur. In short, this is not a portable approach to aliasing annotation declarations, and is precisely what the lookup= attribute is for.

Now as to why it works with Object is a side effect specific to our implementation. Name binding and field injection are distinct processes, and the use of Object means there is no provider available to run the binding portion, yet the lookup portion still runs. The lookup portion uses the names created by the binding portion. This is undefined territory though so I would not rely on it.

As to why this works on other container vendors, the spec allows a lot of freedom there, so they may infer the binding in some cases, although being non-standard you may not be able to rely on the consistency of that behavior. As to why the EE6 tutorial works, the expectation was likely that the unbound entry would have been defined/configured either on the server or via a DD.

> Wildfly doesn't handle @Resource name attribute for DataSource type
> -------------------------------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sat Sep 19 07:31:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Sat, 19 Sep 2015 07:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.46211.1442662260688@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBMETA-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reopened JBMETA-387:
-----------------------------------


This was reverted, per https://github.com/jboss/metadata/pull/90

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 19 07:36:00 2015
From: issues at jboss.org (Jean-Frederic Clere (JIRA))
Date: Sat, 19 Sep 2015 07:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.46217.1442662560248@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBMETA-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110599#comment-13110599 ] 

Jean-Frederic Clere commented on JBMETA-387:
--------------------------------------------

even the changes are only in comments our tests don't allow any changes in xsd... Probably the metadata tests need to be improved before applying the fix.

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Sep 19 17:43:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Sat, 19 Sep 2015 17:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5372) Infinispan's jdbc store
 creates incorrect service name for datasource dependency
In-Reply-To: <JIRA.12585434.1442698974000@Atlassian.JIRA>
References: <JIRA.12585434.1442698974000@Atlassian.JIRA>
	<JIRA.12585434.1442698974991@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585434.1442698974000.46224.1442698980260@Atlassian.JIRA>

Radoslav Husar created WFLY-5372:
------------------------------------

             Summary: Infinispan's jdbc store creates incorrect service name for datasource dependency
                 Key: WFLY-5372
                 URL: https://issues.jboss.org/browse/WFLY-5372
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.CR1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
             Fix For: 10.0.0.CR2


fails with

23:36:38,116 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "clusterbench-ee7.ear")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.clustering.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\"",
        "jboss.clustering.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\"",
        "jboss.clustering.web.locator.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\"",
        "jboss.clustering.web.locator.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\"",
        "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-web-default.war\".deploymentCompleteService",
        "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-web-passivating.war\".deploymentCompleteService",
        "jboss.deployment.unit.\"clusterbench-ee7.ear\".deploymentCompleteService",
        "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\"",
        "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\".config",
        "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\"",
        "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\".config",
        "jboss.undertow.deployment.default-server.default-host./clusterbench",
        "jboss.undertow.deployment.default-server.default-host./clusterbench.UndertowDeploymentInfoService",
        "jboss.undertow.deployment.default-server.default-host./clusterbench.codec",
        "jboss.undertow.deployment.default-server.default-host./clusterbench.session",
        "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating",
        "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating.UndertowDeploymentInfoService",
        "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating.codec",
        "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating.session"
    ],
    "Services that may be the cause:" => ["jboss.data-source.java:jboss/datasources/ExampleDS"]
}}
23:36:38,119 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "infinispan"),
    ("cache-container" => "web")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.clustering.registry.web.default",
        "jboss.infinispan.web.default.config"
    ],
    "Services that may be the cause:" => ["jboss.data-source.java:jboss/datasources/ExampleDS"]
}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 10:19:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 20 Sep 2015 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-990) Eliminate possible races in
 determining if a reconnecting server requires reload
In-Reply-To: <JIRA.12585436.1442758727000@Atlassian.JIRA>
References: <JIRA.12585436.1442758727000@Atlassian.JIRA>
	<JIRA.12585436.1442758727559@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585436.1442758727000.46228.1442758740223@Atlassian.JIRA>

Brian Stansberry created WFCORE-990:
---------------------------------------

             Summary: Eliminate possible races in determining if a reconnecting server requires reload
                 Key: WFCORE-990
                 URL: https://issues.jboss.org/browse/WFCORE-990
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry


Tracking on the HostController as to whether a disconnected server requires reload is vulnerable to races where the slave HC reconnects to the master and makes its calculations and then further changes come in from the DC before the slave's server(s) have reconnected. Those changes should trigger the server going into reload required.

I think the cleanest way to handle this is when the server reconnects instead of replying with a simple boolean as to whether reload required state is needed, the response can be more complex, including, if the HC thinks reload is *not* required, the entire resource tree the HC would currently expect for the server. (I don't expect this to be a trivial task.) The server can then compare that tree to its own. This can be done in a transactional manner, with the server commiting the transaction when its check is completed. This ensures the HC's model controller lock is held throughout, and therefore further changes cannnot come in until the server is fully integrated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 10:47:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Sun, 20 Sep 2015 10:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.46298.1442760420212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110602#comment-13110602 ] 

Paul Ferraro commented on WFLY-5358:
------------------------------------

JGroups properties are subject to deprecations across releases.  This is normal.
This is documented in the description of the associated attribute of the runtime channel (available from the management interface), as well as in the exception message itself.
The exception messages are fairly self-explanatory.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 16:57:00 2015
From: issues at jboss.org (Dmitry Toptygin (JIRA))
Date: Sun, 20 Sep 2015 16:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-766) RuleNetworkEvaluator
 infinite loop when doUpdatesReorderLeftMemory is called
In-Reply-To: <JIRA.12569177.1429707430000@Atlassian.JIRA>
References: <JIRA.12569177.1429707430000@Atlassian.JIRA>
	<JIRA.12569177.1429707430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569177.1429707430000.46306.1442782620383@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110604#comment-13110604 ] 

Dmitry Toptygin commented on DROOLS-766:
----------------------------------------

The problem does not happen in drools 6.3.0.CR2 for me as well. Thanks for fixing this!

> RuleNetworkEvaluator infinite loop when doUpdatesReorderLeftMemory is called
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-766
>                 URL: https://issues.jboss.org/browse/DROOLS-766
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.2.0.Final
>            Reporter: Juan Carlos Garcia
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>         Attachments: infiniteLoopReproducer.jar, infiniteLoopReproducer_src.jar
>
>
> We are migrating our system to use drools 6.2.0.Final from 6.0.1.Final and one of our testcase which actually simulate several complex scenario is making drools (6.2.0.Final) going into an endless loop, while the same works fine in 6.0.1.Final.
> I took a thread dump and it seems stuck:
> {code}
> 	at org.drools.core.phreak.RuleNetworkEvaluator.doUpdatesReorderLeftMemory(RuleNetworkEvaluator.java:795)
> {code}
> While debugging the source code this is what i got:
> # LeftTupleMemory ltm = bm.getLeftTupleMemory(); 
> ** LeftTupleMemory is a LeftTupleList
> # leftTuple.getStagedNext(); 
> ** Always return the same object instance(leftTuple is a JoinNodeLeftTuple type), hence the loop never ends.
> Unfortunately i cannot provide the DRL files + domain classes involve and don't know if it would be even possible for me right now to recreate the same testcase without leaking internal information from the company i work for.
> ThreadDump
> {code}
> "Attach Listener" daemon prio=10 tid=0x00007fdb74001000 nid=0x88c waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "drools-worker-2" daemon prio=10 tid=0x00007fdb54003000 nid=0x803 waiting on condition [0x00007fdb9b7cc000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x0000000783f213f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:745)
> "pool-3-thread-1" prio=10 tid=0x00007fdba46de000 nid=0x764 waiting on condition [0x00007fdb9bbd6000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x0000000783eba160> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:745)
> "Service Thread" daemon prio=10 tid=0x00007fdba40ad800 nid=0x754 runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" daemon prio=10 tid=0x00007fdba40ab000 nid=0x753 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" daemon prio=10 tid=0x00007fdba40a8000 nid=0x752 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "JDWP Command Reader" daemon prio=10 tid=0x00007fdb68001000 nid=0x74e runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "JDWP Event Helper Thread" daemon prio=10 tid=0x00007fdba40a6000 nid=0x74d runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "JDWP Transport Listener: dt_socket" daemon prio=10 tid=0x00007fdba40a2800 nid=0x74c runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0x00007fdba4094800 nid=0x74b runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=10 tid=0x00007fdba4074800 nid=0x74a in Object.wait() [0x00007fdba0cfb000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000007838824e0> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> 	- locked <0x00000007838824e0> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" daemon prio=10 tid=0x00007fdba4072800 nid=0x749 in Object.wait() [0x00007fdba0dfc000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000007838820a0> (a java.lang.ref.Reference$Lock)
> 	at java.lang.Object.wait(Object.java:503)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
> 	- locked <0x00000007838820a0> (a java.lang.ref.Reference$Lock)
> "main" prio=10 tid=0x00007fdba400e800 nid=0x743 runnable [0x00007fdbad9a8000]
>    java.lang.Thread.State: RUNNABLE
> 	at org.drools.core.phreak.RuleNetworkEvaluator.doUpdatesReorderLeftMemory(RuleNetworkEvaluator.java:795)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:38)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:235)
> 	- locked <0x0000000783f2da90> (a org.drools.core.phreak.RuleExecutor)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:106)
> 	- locked <0x0000000783f2da90> (a org.drools.core.phreak.RuleExecutor)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1016)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1302)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1289)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1262)
> 	at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109)
> 	at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34)
> 	at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> 	at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:723)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:697)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 18:34:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 20 Sep 2015 18:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5373) Add a global setting for
 max-active-sessions
In-Reply-To: <JIRA.12585438.1442788438000@Atlassian.JIRA>
References: <JIRA.12585438.1442788438000@Atlassian.JIRA>
	<JIRA.12585438.1442788438809@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585438.1442788438000.46308.1442788440110@Atlassian.JIRA>

Stuart Douglas created WFLY-5373:
------------------------------------

             Summary: Add a global setting for max-active-sessions
                 Key: WFLY-5373
                 URL: https://issues.jboss.org/browse/WFLY-5373
             Project: WildFly
          Issue Type: Feature Request
          Components: Web (Undertow)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 19:38:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 20 Sep 2015 19:38:00 -0400 (EDT)
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.46320.1442792280062@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: 3.0.0.Alpha1
                       (was: 2.0.0.CR2)


> "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: 3.0.0.Alpha1
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 19:56:00 2015
From: issues at jboss.org (Lyle Wang (JIRA))
Date: Sun, 20 Sep 2015 19:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-923) Execution timeout for CLI
	operations
In-Reply-To: <JIRA.12582757.1440656755000@Atlassian.JIRA>
References: <JIRA.12582757.1440656755000@Atlassian.JIRA>
	<JIRA.12582757.1440656755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582757.1440656755000.46326.1442793360146@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110607#comment-13110607 ] 

Lyle Wang commented on WFCORE-923:
----------------------------------

Hi, Alexey:

I think it would be great if it can cancel the current operation and return a error message telling which task it timed out. Is that possible ?

In some customer reported cases we see customer using a batch script file to execute  a set of commands in which, some time-consuming (e.g. upgrade database schema in a deployment) tasks are included. And sometime customer observe that the CLI gets hang up and will not return back.

What customer does now is, to write their own script and "spawn the CLI process in the background and watch the background PID for nnn seconds, and kill it myself if it doesn't complete."

Hope these explain. Thanks

Lyle.

> Execution timeout for CLI operations
> ------------------------------------
>
>                 Key: WFCORE-923
>                 URL: https://issues.jboss.org/browse/WFCORE-923
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Lyle Wang
>            Assignee: Alexey Loubyansky
>              Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy"  inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 20:53:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 20 Sep 2015 20:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5363) [Migration operation] [Web to
 Undertow] Default value for access-log extended attribute differs
In-Reply-To: <JIRA.12585358.1442572428000@Atlassian.JIRA>
References: <JIRA.12585358.1442572428000@Atlassian.JIRA>
	<JIRA.12585358.1442572428000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585358.1442572428000.46340.1442796780077@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110610#comment-13110610 ] 

Stuart Douglas commented on WFLY-5363:
--------------------------------------

This was a mistake, the default should have been false in the Undertow subsystem.

> [Migration operation] [Web to Undertow] Default value for access-log extended attribute differs
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5363
>                 URL: https://issues.jboss.org/browse/WFLY-5363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> When migrating access-log without defined extended attribute results in undertow without defined extended attribute, but the default values differ causing that even though in Web subsystem extended format wasn't used, in Undertow it is expected logging to use extended format.
> Ideally the defaults should be the same or the migrate operation needs to define the extended attribute to false if it wasn't defined in Web.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 21:51:00 2015
From: issues at jboss.org (Ivn Lahav (JIRA))
Date: Sun, 20 Sep 2015 21:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute for DataSource type
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.46346.1442800260271@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110612#comment-13110612 ] 

Ivn Lahav commented on WFLY-5369:
---------------------------------

Hi Jason,

> that the unbound entry would have been defined/configured either on the server or via a DD
But notice that we are doing exactly that. The class-level @Resource annotation is equivalent of DD:
{code}
@Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
{code}
Now, I tried replacing this annotation with the equivalent entry in web.xml:
{code}
<resource-env-ref>
    <resource-env-ref-name>db1</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>	  
    <lookup-name>java:jboss/datasources/ExampleDS</lookup-name>
</resource-env-ref>
{code}
(while keeping the field level annotation) and it started working!

So xml and annotation should produce the same result, yet the annotation doesn't work.


> Wildfly doesn't handle @Resource name attribute for DataSource type
> -------------------------------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 20 21:53:00 2015
From: issues at jboss.org (Ivn Lahav (JIRA))
Date: Sun, 20 Sep 2015 21:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle
 @Resource name attribute for DataSource type
In-Reply-To: <JIRA.12585396.1442587908000@Atlassian.JIRA>
References: <JIRA.12585396.1442587908000@Atlassian.JIRA>
	<JIRA.12585396.1442587908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585396.1442587908000.46350.1442800380133@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110612#comment-13110612 ] 

Ivn Lahav edited comment on WFLY-5369 at 9/20/15 9:52 PM:
----------------------------------------------------------

Hi Jason,

> that the unbound entry would have been defined/configured either on the server or via a DD
But notice that we are doing exactly that. The class-level @Resource annotation is equivalent of DD:
{code}
@Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
{code}
Now, I tried replacing this annotation with the equivalent entry in web.xml:
{code}
<resource-env-ref>
    <resource-env-ref-name>db1</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>	  
    <lookup-name>java:jboss/datasources/ExampleDS</lookup-name>
</resource-env-ref>
{code}
(while keeping the field level annotation) and it started working!

So xml and annotation should produce the same result, yet the annotation doesn't work (when combined with field level annotation).



was (Author: user992281):
Hi Jason,

> that the unbound entry would have been defined/configured either on the server or via a DD
But notice that we are doing exactly that. The class-level @Resource annotation is equivalent of DD:
{code}
@Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
{code}
Now, I tried replacing this annotation with the equivalent entry in web.xml:
{code}
<resource-env-ref>
    <resource-env-ref-name>db1</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>	  
    <lookup-name>java:jboss/datasources/ExampleDS</lookup-name>
</resource-env-ref>
{code}
(while keeping the field level annotation) and it started working!

So xml and annotation should produce the same result, yet the annotation doesn't work.


> Wildfly doesn't handle @Resource name attribute for DataSource type
> -------------------------------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 01:47:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 21 Sep 2015 01:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.46420.1442814420288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-310:
-----------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1083  (was: https://github.com/wildfly/wildfly-core/pull/1070)


> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 01:47:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 21 Sep 2015 01:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-981)
 RemoteDomainConnectionService uses out of date HostInfo data when
 reconnecting
In-Reply-To: <JIRA.12585033.1442365330000@Atlassian.JIRA>
References: <JIRA.12585033.1442365330000@Atlassian.JIRA>
	<JIRA.12585033.1442365330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585033.1442365330000.46423.1442814420354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-981:
-----------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1083  (was: https://github.com/wildfly/wildfly-core/pull/1070)


> RemoteDomainConnectionService uses out of date HostInfo data when reconnecting
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-981
>                 URL: https://issues.jboss.org/browse/WFCORE-981
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta7
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When RemoteDomainConnectionService starts, it calculates a "hostInfo" ModelNode that among other things includes data about what addresses the host is ignoring, and what server groups and socket binding groups are relevant to it if it is ignoring resources unrelated to its servers.
> Problem is, this data is never updated if the host's config changes, so if the host needs to reconnect to the master, it sends out-of-date data to the master, and also uses out of date data to process the info that comes back from the master.
> We need to figure out how to refresh that data for each connection to the master.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 02:18:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 21 Sep 2015 02:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-387) Remove obsolete clustering
 configuration from XSD for jboss-web.xml
In-Reply-To: <JIRA.12573633.1433277270000@Atlassian.JIRA>
References: <JIRA.12573633.1433277270000@Atlassian.JIRA>
	<JIRA.12573633.1433277270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573633.1433277270000.46445.1442816280426@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBMETA-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110629#comment-13110629 ] 

Ladislav Thon commented on JBMETA-387:
--------------------------------------

The change was applied to the latest version (10), it was only reverted in the historical versions. I do believe that the historical versions should be fixed too, so I agree with the reopen.

> Remove obsolete clustering configuration from XSD for jboss-web.xml
> -------------------------------------------------------------------
>
>                 Key: JBMETA-387
>                 URL: https://issues.jboss.org/browse/JBMETA-387
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 8.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The XSD for jboss-web.xml refers to obsolete clustering configuration.
> Also, the comment for <cache-name/> still refers to AS6 syntax.  As of AS7, Cache container and cache are delimited by a ".", not a "/".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 02:35:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 21 Sep 2015 02:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-991) Starting server with config
 that doesn't end with .xml fails
In-Reply-To: <JIRA.12585445.1442817251000@Atlassian.JIRA>
References: <JIRA.12585445.1442817251000@Atlassian.JIRA>
	<JIRA.12585445.1442817251434@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585445.1442817251000.46463.1442817300074@Atlassian.JIRA>

Ken Wills created WFCORE-991:
--------------------------------

             Summary: Starting server with config that doesn't end with .xml fails
                 Key: WFCORE-991
                 URL: https://issues.jboss.org/browse/WFCORE-991
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Ken Wills
            Assignee: Ken Wills


[copy standalone.xml to test in the standalone/config directory]

./build/target/wildfly-core-2.0.0.CR2-SNAPSHOT/bin/standalone.sh --server-config=test
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.CR2-SNAPSHOT

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

01:19:50,510 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
01:19:50,654 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
01:19:50,709 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" starting
01:19:51,110 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
01:19:51,125 INFO  [org.xnio] (MSC service thread 1-4) XNIO version 3.3.2.Final
01:19:51,135 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.3.2.Final
01:19:51,161 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 4.0.10.Final
01:19:51,189 WARN  [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-8) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
01:19:51,264 INFO  [stdout] (Controller Boot Thread) XXX historyBase: /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.CR2-SNAPSHOT/standalone/configuration/standalone_xml_history/test
01:19:51,265 INFO  [stdout] (Controller Boot Thread) XXX lastFile: /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.last.CR2-SNAPSHOT/standalone/configuration/standalone_xml_history/test
01:19:51,265 INFO  [stdout] (Controller Boot Thread) XXX boot: /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.boot.CR2-SNAPSHOT/standalone/configuration/standalone_xml_history/test
01:19:51,265 INFO  [stdout] (Controller Boot Thread) XXX initial: /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.initial.CR2-SNAPSHOT/standalone/configuration/standalone_xml_history/test
01:19:51,265 INFO  [stdout] (Controller Boot Thread) XXX from: /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.CR2-SNAPSHOT/standalone/configuration/test -> /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.initial.CR2-SNAPSHOT/standalone/configuration/standalone_xml_history/test
01:19:51,267 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0082: Failed to create backup copies of configuration file /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.CR2-SNAPSHOT/standalone/configuration/test
	at org.jboss.as.controller.persistence.ConfigurationFile.successfulBoot(ConfigurationFile.java:488)
	at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.successfulBoot(BackupXmlConfigurationPersister.java:94)
	at org.jboss.as.controller.AbstractControllerService.finishBoot(AbstractControllerService.java:449)
	at org.jboss.as.server.ServerService.boot(ServerService.java:367)
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.nio.file.NoSuchFileException: /home/kwills/git/wildfly-core/build/target/wildfly-core-2.0.0.initial.CR2-SNAPSHOT/standalone/configuration/standalone_xml_history/test
	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.UnixCopyFile.copyFile(UnixCopyFile.java:243)
	at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:581)
	at sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253)
	at java.nio.file.Files.copy(Files.java:1274)
	at org.jboss.as.controller.persistence.FilePersistenceUtils.copyFile(FilePersistenceUtils.java:73)
	at org.jboss.as.controller.persistence.ConfigurationFile.successfulBoot(ConfigurationFile.java:482)
	... 5 more

This is due to ConfiguratioinFile.addSuffixToFile(historyBase, INITIAL) assuming that the right most . is part of a file suffix.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 02:37:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 21 Sep 2015 02:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-933) Embedded server start
 commands are lacking argument validation
In-Reply-To: <JIRA.12583128.1440766459000@Atlassian.JIRA>
References: <JIRA.12583128.1440766459000@Atlassian.JIRA>
	<JIRA.12583128.1440766459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583128.1440766459000.46467.1442817420226@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110634#comment-13110634 ] 

Ken Wills commented on WFCORE-933:
----------------------------------

@pkremens I don't see the same blocking behaviour, this may have been resolved by another patch (for AESH etc). I've added some validation for embedded anyway, as it  will fail for other reasons, and opened https://issues.jboss.org/browse/WFCORE-991 to address those.


> Embedded server start commands are lacking argument validation
> --------------------------------------------------------------
>
>                 Key: WFCORE-933
>                 URL: https://issues.jboss.org/browse/WFCORE-933
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> Commands for starting embedded instances are lacking argument validation.
> {noformat}[disconnected /] embed-server foo
> [standalone at embedded /]
> [disconnected /] embed-server foo -foo
> [standalone at embedded /]
> [disconnected /] embed-server foo --foo
> [standalone at embedded /]
> [standalone at embedded /] stop-embedded-server foo
> The command accepts 0 unnamed argument(s) but received: [foo]
> [standalone at embedded /] stop-embedded-server -foo
> Unrecognized arguments: [-foo]
> [standalone at embedded /] stop-embedded-server --foo
> Unrecognized arguments: [--foo]{noformat}
> Same case for embedded host controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 02:57:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 21 Sep 2015 02:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-982) Improve
 ServerRestartRequiredTestCase.testSocketBinding() when used with
 ignore-unused-configuration
In-Reply-To: <JIRA.12585043.1442382844000@Atlassian.JIRA>
References: <JIRA.12585043.1442382844000@Atlassian.JIRA>
	<JIRA.12585043.1442382844000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585043.1442382844000.46521.1442818620074@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills closed WFCORE-982.
----------------------------
    Resolution: Duplicate Issue


Fixed as part of WFCORE-310

> Improve ServerRestartRequiredTestCase.testSocketBinding() when used with ignore-unused-configuration
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-982
>                 URL: https://issues.jboss.org/browse/WFCORE-982
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Currently this test adds an unused socket-binding-group that it assumes will not be ignored on the slave. Since the SBG is unused, it is ignored.
> This test should just actually bind something to use the SBG, so the slave picks it up.
> For now, the testsuite host-slave.xml has the bogus reload-sockets added statically.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 03:01:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Mon, 21 Sep 2015 03:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-933) Embedded server start
 commands are lacking argument validation
In-Reply-To: <JIRA.12583128.1440766459000@Atlassian.JIRA>
References: <JIRA.12583128.1440766459000@Atlassian.JIRA>
	<JIRA.12583128.1440766459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583128.1440766459000.46525.1442818860383@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110645#comment-13110645 ] 

Petr Kremensky commented on WFCORE-933:
---------------------------------------

You're right, re-tested with the latest EAP build (based on WildFly Core 2.0.0.CR1)  and this no longer blocks.

> Embedded server start commands are lacking argument validation
> --------------------------------------------------------------
>
>                 Key: WFCORE-933
>                 URL: https://issues.jboss.org/browse/WFCORE-933
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> Commands for starting embedded instances are lacking argument validation.
> {noformat}[disconnected /] embed-server foo
> [standalone at embedded /]
> [disconnected /] embed-server foo -foo
> [standalone at embedded /]
> [disconnected /] embed-server foo --foo
> [standalone at embedded /]
> [standalone at embedded /] stop-embedded-server foo
> The command accepts 0 unnamed argument(s) but received: [foo]
> [standalone at embedded /] stop-embedded-server -foo
> Unrecognized arguments: [-foo]
> [standalone at embedded /] stop-embedded-server --foo
> Unrecognized arguments: [--foo]{noformat}
> Same case for embedded host controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 03:59:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 21 Sep 2015 03:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-945) Cannot start embedded host
 controller in non-modular classloading environment
In-Reply-To: <JIRA.12583562.1441195388000@Atlassian.JIRA>
References: <JIRA.12583562.1441195388000@Atlassian.JIRA>
	<JIRA.12583562.1441195388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583562.1441195388000.46653.1442822340215@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110660#comment-13110660 ] 

Ken Wills commented on WFCORE-945:
----------------------------------

This currently works for me:

$ pwd
/home/kwills/git/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/bin/client

$  java -jar jboss-cli-client.jar 
WARN: can't find jboss-cli.xml. Using default configuration values.
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server --jboss-home=/home/kwills/git/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT
Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
[standalone at embedded /] ls 
core-service                               namespaces=[]                              
deployment                                 organization=undefined                     
...

[standalone at embedded /] stop-embedded-server 

[disconnected /] embed-host-controller --jboss-home=/home/kwills/git/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT
02:39:38,539 INFO  [org.jboss.modules] (AeshProcess: 4) JBoss Modules version (unknown)
Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
[domain at embedded /] ls
core-service                         launch-type=DOMAIN                   
deployment                           local-host-name=master               
...
[domain at embedded /] stop-embedded-host-controller 
[disconnected /] 

> Cannot start embedded host controller in non-modular classloading environment
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-945
>                 URL: https://issues.jboss.org/browse/WFCORE-945
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Trying to start embedded host controller inside CLI running i in non-modular classloading environment gives me NPE.
> {noformat}
> $ unzip -q jboss-eap-7.0.0.DR9.zip 
> $ cd jboss-eap-7.0/bin/client/
> $ pwd
> /home/hudson/users-tmp/pkremens/jboss-eap-7.0/bin/client
> $ java -jar jboss-cli-client.jar 
> WARN: can't find jboss-cli.xml. Using default configuration values.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
> [standalone at embedded /] stop-embedded-server 
> [disconnected /] embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Failed to handle 'embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0': java.lang.NullPointerException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 03:59:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 21 Sep 2015 03:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-945) Cannot start embedded host
 controller in non-modular classloading environment
In-Reply-To: <JIRA.12583562.1441195388000@Atlassian.JIRA>
References: <JIRA.12583562.1441195388000@Atlassian.JIRA>
	<JIRA.12583562.1441195388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583562.1441195388000.46656.1442822340290@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills resolved WFCORE-945.
------------------------------
    Resolution: Cannot Reproduce Bug


> Cannot start embedded host controller in non-modular classloading environment
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-945
>                 URL: https://issues.jboss.org/browse/WFCORE-945
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Trying to start embedded host controller inside CLI running i in non-modular classloading environment gives me NPE.
> {noformat}
> $ unzip -q jboss-eap-7.0.0.DR9.zip 
> $ cd jboss-eap-7.0/bin/client/
> $ pwd
> /home/hudson/users-tmp/pkremens/jboss-eap-7.0/bin/client
> $ java -jar jboss-cli-client.jar 
> WARN: can't find jboss-cli.xml. Using default configuration values.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
> [standalone at embedded /] stop-embedded-server 
> [disconnected /] embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Failed to handle 'embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0': java.lang.NullPointerException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 04:18:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Mon, 21 Sep 2015 04:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-945) Cannot start embedded host
 controller in non-modular classloading environment
In-Reply-To: <JIRA.12583562.1441195388000@Atlassian.JIRA>
References: <JIRA.12583562.1441195388000@Atlassian.JIRA>
	<JIRA.12583562.1441195388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583562.1441195388000.46686.1442823480248@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110664#comment-13110664 ] 

Petr Kremensky commented on WFCORE-945:
---------------------------------------

I can confirm, this works with the latest EAP build (based on WildFly Core 2.0.0.CR1).

> Cannot start embedded host controller in non-modular classloading environment
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-945
>                 URL: https://issues.jboss.org/browse/WFCORE-945
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR2
>
>
> Trying to start embedded host controller inside CLI running i in non-modular classloading environment gives me NPE.
> {noformat}
> $ unzip -q jboss-eap-7.0.0.DR9.zip 
> $ cd jboss-eap-7.0/bin/client/
> $ pwd
> /home/hudson/users-tmp/pkremens/jboss-eap-7.0/bin/client
> $ java -jar jboss-cli-client.jar 
> WARN: can't find jboss-cli.xml. Using default configuration values.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
> [standalone at embedded /] stop-embedded-server 
> [disconnected /] embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0
> Failed to handle 'embed-host-controller --jboss-home=/home/hudson/users-tmp/pkremens/jboss-eap-7.0': java.lang.NullPointerException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 04:22:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Sep 2015 04:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.46713.1442823720261@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110667#comment-13110667 ] 

RH Bugzilla Integration commented on WFLY-5332:
-----------------------------------------------

Panagiotis Sotiropoulos <psotirop at redhat.com> changed the Status of [bug 1255494|https://bugzilla.redhat.com/show_bug.cgi?id=1255494] from ASSIGNED to POST

> Allow configure max-threads and core-threads independently
> ----------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 04:53:00 2015
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 21 Sep 2015 04:53:00 -0400 (EDT)
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.46805.1442825580233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman resolved WFLY-4818.
--------------------------------
    Resolution: Done


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:13:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 05:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.46880.1442826780265@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-715:
-------------------------------
    Affects Version/s: 1.0.1.Final


> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Tomaz Cerar
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:15:02 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 05:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.46889.1442826902758@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110687#comment-13110687 ] 

Tomaz Cerar commented on WFCORE-715:
------------------------------------

[~renan.galang] what JDK version did you use? 

> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Tomaz Cerar
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:22:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
	1.8 (64-bit)
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46923.1442827320239@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak moved JBEAP-1118 to WFLY-5374:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5374  (was: JBEAP-1118)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Server
                           (was: Server)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR10 (Alpha))


> Server start-up fails on IBM 1.8 (64-bit)
> -----------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10 fails to start on IBM 1.8 (64) on RHEL 6/7.
> Console log:
> [hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:22:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
	1.8 (64-bit)
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46929.1442827320470@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5374:
---------------------------------
    Description: 
EAP 7.0.0.DR10 fails to start on IBM 1.8 (64) on RHEL 6/7.

Console log:
{code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /tmp/dr10/jboss-eap-7.0

  JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
R14=00007F0FD02A9020 R15=0000000000000000
RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
Module_base_address=00007F100C58E000
Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
----------- Stack Backtrace -----------
(0x00007F100C606C45 [libj9vm28.so+0x78c45])
(0x00007F100C61BECA [libj9vm28.so+0x8deca])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".
{code}

Java version:
{code}java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
J9VM - R28_jvm.28_20150630_1742_B255633
JIT  - tr.r14.java_20150625_95081.01
GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
J9CL - 20150630_255633)
JCL - 20150711_01 based on Oracle jdk8u51-b15
{code}

  was:
EAP 7.0.0.DR10 fails to start on IBM 1.8 (64) on RHEL 6/7.

Console log:
[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /tmp/dr10/jboss-eap-7.0

  JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
R14=00007F0FD02A9020 R15=0000000000000000
RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
Module_base_address=00007F100C58E000
Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
----------- Stack Backtrace -----------
(0x00007F100C606C45 [libj9vm28.so+0x78c45])
(0x00007F100C61BECA [libj9vm28.so+0x8deca])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".


Java version:
{code}java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
J9VM - R28_jvm.28_20150630_1742_B255633
JIT  - tr.r14.java_20150625_95081.01
GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
J9CL - 20150630_255633)
JCL - 20150711_01 based on Oracle jdk8u51-b15
{code}



> Server start-up fails on IBM 1.8 (64-bit)
> -----------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10 fails to start on IBM 1.8 (64) on RHEL 6/7.
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:25:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46945.1442827500108@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5374:
---------------------------------
    Summary: Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7  (was: Server start-up fails on IBM 1.8 (64-bit))


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7
> ---------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10 fails to start on IBM 1.8 (64) on RHEL 6/7.
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:26:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46948.1442827560232@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5374:
---------------------------------
    Description: 
EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7.

Console log:
{code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /tmp/dr10/jboss-eap-7.0

  JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
R14=00007F0FD02A9020 R15=0000000000000000
RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
Module_base_address=00007F100C58E000
Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
----------- Stack Backtrace -----------
(0x00007F100C606C45 [libj9vm28.so+0x78c45])
(0x00007F100C61BECA [libj9vm28.so+0x8deca])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".
{code}

Java version:
{code}java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
J9VM - R28_jvm.28_20150630_1742_B255633
JIT  - tr.r14.java_20150625_95081.01
GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
J9CL - 20150630_255633)
JCL - 20150711_01 based on Oracle jdk8u51-b15
{code}

  was:
EAP 7.0.0.DR10 fails to start on IBM 1.8 (64) on RHEL 6/7.

Console log:
{code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /tmp/dr10/jboss-eap-7.0

  JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
R14=00007F0FD02A9020 R15=0000000000000000
RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
Module_base_address=00007F100C58E000
Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
----------- Stack Backtrace -----------
(0x00007F100C606C45 [libj9vm28.so+0x78c45])
(0x00007F100C61BECA [libj9vm28.so+0x8deca])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".
{code}

Java version:
{code}java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
J9VM - R28_jvm.28_20150630_1742_B255633
JIT  - tr.r14.java_20150625_95081.01
GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
J9CL - 20150630_255633)
JCL - 20150711_01 based on Oracle jdk8u51-b15
{code}



> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7
> ---------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7.
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:30:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46963.1442827800196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5374:
---------------------------------
    Summary: Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile  (was: Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7)


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7.
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:30:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46966.1442827800339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5374:
---------------------------------
    Description: 
EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 

Console log:
{code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /tmp/dr10/jboss-eap-7.0

  JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
R14=00007F0FD02A9020 R15=0000000000000000
RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
Module_base_address=00007F100C58E000
Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
----------- Stack Backtrace -----------
(0x00007F100C606C45 [libj9vm28.so+0x78c45])
(0x00007F100C61BECA [libj9vm28.so+0x8deca])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".
{code}

Java version:
{code}java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
J9VM - R28_jvm.28_20150630_1742_B255633
JIT  - tr.r14.java_20150625_95081.01
GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
J9CL - 20150630_255633)
JCL - 20150711_01 based on Oracle jdk8u51-b15
{code}

  was:
EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7.

Console log:
{code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /tmp/dr10/jboss-eap-7.0

  JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
Unhandled exception
Type=Segmentation error vmState=0x00000000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
R14=00007F0FD02A9020 R15=0000000000000000
RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
Module_base_address=00007F100C58E000
Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
----------- Stack Backtrace -----------
(0x00007F100C606C45 [libj9vm28.so+0x78c45])
(0x00007F100C61BECA [libj9vm28.so+0x8deca])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
JVMDUMP013I Processed dump event "gpf", detail "".
{code}

Java version:
{code}java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
J9VM - R28_jvm.28_20150630_1742_B255633
JIT  - tr.r14.java_20150625_95081.01
GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
J9CL - 20150630_255633)
JCL - 20150711_01 based on Oracle jdk8u51-b15
{code}



> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:32:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46977.1442827920182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5374:
---------------------------------
    Component/s: JMS


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:33:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 05:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.46987.1442827980365@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110694#comment-13110694 ] 

Miroslav Novak commented on WFLY-5374:
--------------------------------------

I tried to remove messaging-activemq subsystem and server started without error. Upgrade of ActiveMQ Artemis causes this regression.

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 05:37:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 05:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.47004.1442828220688@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110696#comment-13110696 ] 

Tomaz Cerar commented on WFLY-5374:
-----------------------------------

This looks related to messaging and aritmetis loading native libs.
I cannot reproduce this locally, can you post core dump file
it should be this one: /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:14:00 2015
From: issues at jboss.org (Ja kub (JIRA))
Date: Mon, 21 Sep 2015 06:14:00 -0400 (EDT)
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.47093.1442830440423@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110705#comment-13110705 ] 

Ja kub commented on WFLY-5309:
------------------------------

Which version of richfaces-components-ui should I use together with richfaces-core v 4.5.8.Final?
When using [richfaces-components-ui-4.3.7.Final.jar I get error as below:

12:10:06,030 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Critical error during deployment: : java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.richfaces.javascript.ClientScriptServiceImpl
        at org.richfaces.javascript.ClientScriptServiceImpl.<init>(ClientScriptServiceImpl.java:57) [richfaces-components-ui-4.3.7.Final.jar:4.5.9.Final]
        at org.richfaces.application.ValidatorModule.createClientScriptService(ValidatorModule.java:66) [richfaces-components-ui-4.3.7.Final.jar:4.5.9.Final]
        at org.richfaces.application.ValidatorModule.configure(ValidatorModule.java:60) [richfaces-components-ui-4.3.7.Final.jar:4.5.9.Final]
        at org.richfaces.application.ServicesFactoryImpl.init(ServicesFactoryImpl.java:60) [richfaces-core-4.5.9.Final.jar:4.5.9.Final]
        at org.richfaces.application.InitializationListener.createFactory(InitializationListener.java:110) [richfaces-core-4.5.9.Final.jar:4.5.9.Final]
        at org.richfaces.application.InitializationListener.onStart(InitializationListener.java:69) [richfaces-core-4.5.9.Final.jar:4.5.9.Final]
        at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:167) [richfaces-core-4.5.9.Final.jar:4.5.9.Final]
        at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
        at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:]
        at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:]
        at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:]
        at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final]
        at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:691) [jsf-impl-2.2.5-jbossorg-3.jar:]
        at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:253) [jsf-impl-2.2.5-jbossorg-3.jar:]
        at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
        at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:187) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
        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) [rt.jar:1.7.0_79]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]

> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:21:00 2015
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 21 Sep 2015 06:21:00 -0400 (EDT)
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.47097.1442830860215@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated WFLY-5232:
--------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/8073


> 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: Jason Greene
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:28:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 06:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.47113.1442831280340@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5374:
---------------------------------
    Attachment: javacore.20150921.051514.4815.0002.txt


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:31:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Mon, 21 Sep 2015 06:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.47136.1442831460437@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110709#comment-13110709 ] 

Miroslav Novak commented on WFLY-5374:
--------------------------------------

Thanks Tomaz for looking at it. I've attached javacore.20150921.051514.4815.0002.txt. Let me know if JIT/System dump as needed.

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Server
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:42:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 21 Sep 2015 06:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077720@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.47184.1442832120149@Atlassian.JIRA>

Ladislav Thon created WFCORE-992:
------------------------------------

             Summary: Memory leak in host controller
                 Key: WFCORE-992
                 URL: https://issues.jboss.org/browse/WFCORE-992
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ladislav Thon
            Assignee: Brian Stansberry
            Priority: Blocker


The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:

{code}
cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in EAP 7.0.0.DR10, or current master
mvn clean install -DskipTests
cd testsuite/domain
mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
{code}

After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:

{code}
2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
{code}

Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:42:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 21 Sep 2015 06:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.47187.1442832120243@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFCORE-992:
---------------------------------
    Description: 
The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:

{code}
cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
mvn clean install -DskipTests
cd testsuite/domain
mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
{code}

After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:

{code}
2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
{code}

Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.

  was:
The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:

{code}
cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in EAP 7.0.0.DR10, or current master
mvn clean install -DskipTests
cd testsuite/domain
mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
{code}

After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:

{code}
2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
{code}

Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



> Memory leak in host controller
> ------------------------------
>
>                 Key: WFCORE-992
>                 URL: https://issues.jboss.org/browse/WFCORE-992
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Blocker
>
> The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:
> {code}
> cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
> mvn clean install -DskipTests
> cd testsuite/domain
> mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
> {code}
> After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:
> {code}
> 2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
> 2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
> 2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
> 2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
> 2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
> 2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
> {code}
> Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:55:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 21 Sep 2015 06:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.47223.1442832900165@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110721#comment-13110721 ] 

Ladislav Thon commented on WFCORE-992:
--------------------------------------

This PR has a fix: https://github.com/wildfly/wildfly-core/pull/1090

I'm not sure whether this is a fix you want to apply. For example, if the {{TransactionalProtocolClientImpl.execute}} method returned a subclass of {{ConvertingDelegatingAsyncFuture}} (instead of {{AbstractDelegatingAsyncFuture}}), the problem would be gone too. So I'm leaving the decision to you (and not assigning this issue to myself).

> Memory leak in host controller
> ------------------------------
>
>                 Key: WFCORE-992
>                 URL: https://issues.jboss.org/browse/WFCORE-992
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Blocker
>
> The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:
> {code}
> cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
> mvn clean install -DskipTests
> cd testsuite/domain
> mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
> {code}
> After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:
> {code}
> 2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
> 2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
> 2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
> 2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
> 2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
> 2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
> {code}
> Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:56:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 21 Sep 2015 06:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.47228.1442832960498@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFCORE-992:
---------------------------------
    Priority: Critical  (was: Blocker)


> Memory leak in host controller
> ------------------------------
>
>                 Key: WFCORE-992
>                 URL: https://issues.jboss.org/browse/WFCORE-992
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:
> {code}
> cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
> mvn clean install -DskipTests
> cd testsuite/domain
> mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
> {code}
> After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:
> {code}
> 2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
> 2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
> 2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
> 2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
> 2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
> 2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
> {code}
> Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 06:57:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 21 Sep 2015 06:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.47251.1442833020328@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFCORE-992:
---------------------------------
    Affects Version/s: 2.0.0.CR1


> Memory leak in host controller
> ------------------------------
>
>                 Key: WFCORE-992
>                 URL: https://issues.jboss.org/browse/WFCORE-992
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:
> {code}
> cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
> mvn clean install -DskipTests
> cd testsuite/domain
> mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
> {code}
> After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:
> {code}
> 2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
> 2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
> 2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
> 2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
> 2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
> 2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
> {code}
> Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 07:16:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 21 Sep 2015 07:16:00 -0400 (EDT)
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.47326.1442834160159@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110734#comment-13110734 ] 

Dmitrii Tikhomirov commented on WFLY-5309:
------------------------------------------

I think, you should use richfaces-core and richfaces, because richfaces already contains the richfaces-ui components, please try and let me know the results.
According to https://github.com/richfaces/richfaces/blob/master/README.adoc#getting-started :
Prior releases of RichFaces required using a BOM to manage the project dependencies. With RichFaces 4.5 all required dependencies are managed transitively, simplifying your project setup.

> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 07:17:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 21 Sep 2015 07:17:00 -0400 (EDT)
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.47332.1442834220128@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108404#comment-13108404 ] 

Dmitrii Tikhomirov edited comment on WFLY-5309 at 9/21/15 7:16 AM:
-------------------------------------------------------------------

You should use RichFaces 4.5.8.Final. Please put it in your pom.xml

		<dependency>
			<groupId>org.richfaces</groupId>
			<artifactId>richfaces</artifactId>
			<version>4.5.8.Final</version>
		</dependency>
... and build again.



was (Author: treblereel):
You should use RichFaces 4.5.8.Final. Please put it in your pom.xml

		<dependency>
			<groupId>org.richfaces</groupId>
			<artifactId>richfaces-core</artifactId>
			<version>4.5.8.Final</version>
		</dependency>
... and build again.


> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 07:31:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Mon, 21 Sep 2015 07:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.47375.1442835060327@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Kremensky moved JBEAP-1121 to WFCORE-993:
----------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-993  (was: JBEAP-1121)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: CLI
                           (was: CLI)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.CR1
                           (was: 7.0.0.DR10 (Alpha))


> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 07:34:00 2015
From: issues at jboss.org (Wessel Pieterse (JIRA))
Date: Mon, 21 Sep 2015 07:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5325) When Making any JAXRS rest
 call NPE is being thrown in
 org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
In-Reply-To: <JIRA.12584677.1441975568000@Atlassian.JIRA>
References: <JIRA.12584677.1441975568000@Atlassian.JIRA>
	<JIRA.12584677.1441975568000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584677.1441975568000.47405.1442835240114@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110743#comment-13110743 ] 

Wessel Pieterse commented on WFLY-5325:
---------------------------------------

The following line in the org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter :

InterceptorChain chain = PhaseInterceptorChain.getCurrentMessage().getInterceptorChain();

Is throwing a null pointer error. It seems like the InterceptorrChain resolves to 0. Might his be a threading issue?

> When Making any JAXRS rest call NPE is being thrown in  org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5325
>                 URL: https://issues.jboss.org/browse/WFLY-5325
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Wessel Pieterse
>            Assignee: Jason Greene
>
> The follwing line in my CORSFilter :
> {code:java}
> chain.doFilter(request, response);
> {code}
> causes
> {code:java}
> wildfly_1      | 12:41:34,692 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-8) Unknown exception while executing POST /orders/214/pay/creditcard/payu: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
> wildfly_1      | 
> wildfly_1      | 12:41:34,693 ERROR [com.unijunction.ordercloud.filter.CORSFilter] (default task-8) CORSFilter failed :: javax.servlet.ServletException: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.cleanup(AdviceFilter.java:196)
> wildfly_1      | 	at org.apache.shiro.web.filter.authc.AuthenticatingFilter.cleanup(AuthenticatingFilter.java:155)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:148)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
> wildfly_1      | Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> wildfly_1      | 	at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	... 52 more
> wildfly_1      | Caused by: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> wildfly_1      | 	... 65 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 07:42:00 2015
From: issues at jboss.org (Wessel Pieterse (JIRA))
Date: Mon, 21 Sep 2015 07:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5325) When Making any JAXRS rest
 call NPE is being thrown in
 org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
In-Reply-To: <JIRA.12584677.1441975568000@Atlassian.JIRA>
References: <JIRA.12584677.1441975568000@Atlassian.JIRA>
	<JIRA.12584677.1441975568000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584677.1441975568000.47422.1442835720382@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110743#comment-13110743 ] 

Wessel Pieterse edited comment on WFLY-5325 at 9/21/15 7:41 AM:
----------------------------------------------------------------

The following line in the org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter :

InterceptorChain chain = PhaseInterceptorChain.getCurrentMessage().getInterceptorChain();

Is throwing a null pointer error. It seems like the InterceptorrChain resolves to 0. Might this be a threading issue?


was (Author: wesseloc):
The following line in the org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter :

InterceptorChain chain = PhaseInterceptorChain.getCurrentMessage().getInterceptorChain();

Is throwing a null pointer error. It seems like the InterceptorrChain resolves to 0. Might his be a threading issue?

> When Making any JAXRS rest call NPE is being thrown in  org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5325
>                 URL: https://issues.jboss.org/browse/WFLY-5325
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Wessel Pieterse
>            Assignee: Jason Greene
>
> The follwing line in my CORSFilter :
> {code:java}
> chain.doFilter(request, response);
> {code}
> causes
> {code:java}
> wildfly_1      | 12:41:34,692 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-8) Unknown exception while executing POST /orders/214/pay/creditcard/payu: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
> wildfly_1      | 
> wildfly_1      | 12:41:34,693 ERROR [com.unijunction.ordercloud.filter.CORSFilter] (default task-8) CORSFilter failed :: javax.servlet.ServletException: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.cleanup(AdviceFilter.java:196)
> wildfly_1      | 	at org.apache.shiro.web.filter.authc.AuthenticatingFilter.cleanup(AuthenticatingFilter.java:155)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:148)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
> wildfly_1      | Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> wildfly_1      | 	at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	... 52 more
> wildfly_1      | Caused by: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> wildfly_1      | 	... 65 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 08:51:00 2015
From: issues at jboss.org (Ja kub (JIRA))
Date: Mon, 21 Sep 2015 08:51:00 -0400 (EDT)
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.123.1442839860777@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110821#comment-13110821 ] 

Ja kub commented on WFLY-5309:
------------------------------

Thx, it helped.
Now I use only
<org.richfaces.version>4.5.9.Final</org.richfaces.version>
		<dependency>
			<groupId>org.richfaces</groupId>
			<artifactId>richfaces</artifactId>
			<version>${org.richfaces.version}</version>
		</dependency>
and nothing else, richfaces-core in included in richfaces

[INFO] +- com.sun.faces:jsf-api:jar:2.2.2:provided
[INFO] +- com.sun.faces:jsf-impl:jar:2.2.2:provided
[INFO] +- org.richfaces:richfaces:jar:4.5.9.Final:compile
[INFO] |  +- org.richfaces:richfaces-core:jar:4.5.9.Final:compile
[INFO] |  |  +- net.sourceforge.cssparser:cssparser:jar:0.9.16:compile
[INFO] |  |  |  \- org.w3c.css:sac:jar:1.3:compile
[INFO] |  |  \- com.google.guava:guava:jar:18.0:compile
[INFO] |  \- org.richfaces:richfaces-a4j:jar:4.5.9.Final:compile

> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 08:55:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Sep 2015 08:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.146.1442840100141@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110825#comment-13110825 ] 

RH Bugzilla Integration commented on DROOLS-924:
------------------------------------------------

Kris Verlaenen <kverlaen at redhat.com> changed the Status of [bug 1264541|https://bugzilla.redhat.com/show_bug.cgi?id=1264541] from NEW to ASSIGNED

> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 09:31:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.290.1442842260490@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-5374:
------------------------------
    Component/s:     (was: Server)


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 09:31:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.299.1442842260719@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-5374:
---------------------------------

    Assignee: Jeff Mesnil  (was: Jason Greene)


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 09:55:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 09:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.380.1442843700196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-992:
------------------------------------
    Fix Version/s: 2.0.0.CR2


> Memory leak in host controller
> ------------------------------
>
>                 Key: WFCORE-992
>                 URL: https://issues.jboss.org/browse/WFCORE-992
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:
> {code}
> cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
> mvn clean install -DskipTests
> cd testsuite/domain
> mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
> {code}
> After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:
> {code}
> 2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
> 2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
> 2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
> 2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
> 2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
> 2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
> {code}
> Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 10:02:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 21 Sep 2015 10:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5375) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068093@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.397.1442844120184@Atlassian.JIRA>

Heiko Braun created WFLY-5375:
---------------------------------

             Summary: Inconsistent :rrd(access-control) response when querying host resources
                 Key: WFLY-5375
                 URL: https://issues.jboss.org/browse/WFLY-5375
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry


{noformat}
[domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [("host" => "macbook-pro.fritz.box")],
            "outcome" => "success",
            "result" => {
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {}
                    },
                    "exceptions" => {}
                },
                "description" => undefined
            }
        },
        {
            "address" => [("host" => "master")],
            "outcome" => "success",
            "result" => {
                "description" => undefined,
                "attributes" => undefined,
                "operations" => undefined,
                "notifications" => undefined,
                "children" => {
                    "core-service" => {"model-description" => undefined},
                    "jvm" => {"model-description" => undefined},
                    "socket-binding-group" => {"model-description" => undefined},
                    "path" => {"model-description" => undefined},
                    "server" => {"model-description" => undefined},
                    "subsystem" => {"model-description" => undefined},
                    "server-config" => {"model-description" => undefined},
                    "interface" => {"model-description" => undefined},
                    "system-property" => {"model-description" => undefined},
                    "extension" => {"model-description" => undefined}
                },
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "directory-grouping" => {
                                "read" => true,
                                "write" => true
                            },
                            "domain-controller" => {
                                "read" => true,
                                "write" => true
                            },
                            "domain-organization" => {
                                "read" => true,
                                "write" => true
                            },
                            "host-state" => {
                                "read" => true,
                                "write" => true
                            },
                            "management-major-version" => {
                                "read" => true,
                                "write" => true
                            },
                            "management-micro-version" => {
                                "read" => true,
                                "write" => true
                            },
                            "management-minor-version" => {
                                "read" => true,
                                "write" => true
                            },
                            "master" => {
                                "read" => true,
                                "write" => true
                            },
                            "name" => {
                                "read" => true,
                                "write" => true
                            },
                            "namespaces" => {
                                "read" => true,
                                "write" => true
                            },
                            "organization" => {
                                "read" => true,
                                "write" => true
                            },
                            "product-name" => {
                                "read" => true,
                                "write" => true
                            },
                            "product-version" => {
                                "read" => true,
                                "write" => true
                            },
                            "release-codename" => {
                                "read" => true,
                                "write" => true
                            },
                            "release-version" => {
                                "read" => true,
                                "write" => true
                            },
                            "running-mode" => {
                                "read" => true,
                                "write" => true
                            },
                            "schema-locations" => {
                                "read" => true,
                                "write" => true
                            },
                            "server-state" => {
                                "read" => true,
                                "write" => true
                            },
                            "suspend-state" => {
                                "read" => true,
                                "write" => true
                            },
                            "uuid" => {
                                "read" => true,
                                "write" => true
                            }
                        }
                    },
                    "exceptions" => {}
                }
            }
        }
    ]
}
[domain at localhost:9990 /] 

{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 10:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 10:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.570.1442845680466@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-5375 to WFCORE-994:
-----------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-994  (was: WFLY-5375)
    Component/s: Domain Management
                     (was: Domain Management)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 10:31:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 10:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.579.1442845860136@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110882#comment-13110882 ] 

Brian Stansberry edited comment on WFCORE-994 at 9/21/15 10:30 AM:
-------------------------------------------------------------------

Is the issue here that the result for "host" => "master" is not trimming the descriptions?



> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 10:51:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 10:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4852) (XNIO-2 I/O-1) XNIO001007
 java.util.concurrent.RejectedExecutionException error shown intermittently
 during server shutdown
In-Reply-To: <JIRA.12576739.1435747528000@Atlassian.JIRA>
References: <JIRA.12576739.1435747528000@Atlassian.JIRA>
	<JIRA.12576739.1435747528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576739.1435747528000.635.1442847060188@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110890#comment-13110890 ] 

Brian Stansberry commented on WFLY-4852:
----------------------------------------

WFLY-4852 has a fuller stack trace and an attached log than WFCORE-756 does, so people looking into 756 should refer to it.

> (XNIO-2 I/O-1) XNIO001007 java.util.concurrent.RejectedExecutionException error shown intermittently during server shutdown
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4852
>                 URL: https://issues.jboss.org/browse/WFLY-4852
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jason Greene
>         Attachments: JPAProxyCrashRecoveryTestCase_haltConnectionAfterDbCommits_jta_server.log
>
>
> Exception
> {code}
> ERROR [org.xnio.listener] (XNIO-2 I/O-1) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 2d696007 rejected from org.xnio.XnioWorker$TaskPool at 74a153ee[Shutting down, pool size = 9, active threads = 0, queued tasks = 0, completed tasks = 50]
> {code}, details at [1]
> could be hit when stopping server. This happens intermediately.
> I run transaction integration tests on WildFly/EAP7 DR builds. My tests works in way of doing some settings via CLI, deploy application, do the test, undeploy application, stop the server.
> During the stopping the server this exception is shown in log.
> Adding server log from my test for possible more details.
> [1]
> {code}
> INFO  [org.jboss.as.server] (Thread-3) WFLYSRV0220: Server shutdown has been requested.
> INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = module_ojdbc7.jar
> INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-1) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> INFO  [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 77) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Stopped Driver service with driver-name = h2
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0019: Host default-host stopping
> ERROR [org.xnio.listener] (XNIO-2 I/O-1) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 2d696007 rejected from org.xnio.XnioWorker$TaskPool at 74a153ee[Shutting down, pool size = 9, active threads = 0, queued tasks = 0, completed tasks = 50]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364)
> at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.channels.TranslatingSuspendableChannel.close(TranslatingSuspendableChannel.java:906)
> at org.xnio.IoUtils.safeClose(IoUtils.java:134)
> at org.xnio.channels.TranslatingSuspendableChannel$3.handleEvent(TranslatingSuspendableChannel.java:133)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.StreamConnection.invokeCloseListener(StreamConnection.java:80)
> at org.xnio.Connection.writeClosed(Connection.java:117)
> at org.xnio.nio.AbstractNioStreamConnection.writeClosed(AbstractNioStreamConnection.java:47)
> at org.xnio.nio.NioSocketConduit.terminateWrites(NioSocketConduit.java:181)
> at org.xnio.nio.NioSocketConduit.truncateWrites(NioSocketConduit.java:191)
> at org.xnio.conduits.ConduitStreamSinkChannel.close(ConduitStreamSinkChannel.java:186)
> at org.xnio.IoUtils.safeClose(IoUtils.java:134)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.forceTermination(WriteReadyHandler.java:57)
> at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:107)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:490)
> INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 71) AMQ151003: resource adaptor stopped
> INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.0.0 [8e39e2e6-1fc3-11e5-b5ab-adb038d9447d] stopped
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending
> INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032018: Destroying TransactionManagerService
> INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032014: Stopping transaction recovery manager
> DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-3) PeriodicRecovery: Mode <== TERMINATED
> DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-3) PeriodicRecovery: shutdown scan wait complete
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to localhost/127.0.0.1:8080
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.0.Beta2 stopping
> INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Alpha5) stopped in 237ms
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 21 10:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4852) (XNIO-2 I/O-1) XNIO001007
 java.util.concurrent.RejectedExecutionException error shown intermittently
 during server shutdown
In-Reply-To: <JIRA.12576739.1435747528000@Atlassian.JIRA>
References: <JIRA.12576739.1435747528000@Atlassian.JIRA>
	<JIRA.12576739.1435747528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576739.1435747528000.640.1442847120796@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-4852.
------------------------------------
      Assignee: Brian Stansberry  (was: Jason Greene)
    Resolution: Duplicate Issue


> (XNIO-2 I/O-1) XNIO001007 java.util.concurrent.RejectedExecutionException error shown intermittently during server shutdown
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4852
>                 URL: https://issues.jboss.org/browse/WFLY-4852
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ond?ej Chaloupka
>            Assignee: Brian Stansberry
>         Attachments: JPAProxyCrashRecoveryTestCase_haltConnectionAfterDbCommits_jta_server.log
>
>
> Exception
> {code}
> ERROR [org.xnio.listener] (XNIO-2 I/O-1) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 2d696007 rejected from org.xnio.XnioWorker$TaskPool at 74a153ee[Shutting down, pool size = 9, active threads = 0, queued tasks = 0, completed tasks = 50]
> {code}, details at [1]
> could be hit when stopping server. This happens intermediately.
> I run transaction integration tests on WildFly/EAP7 DR builds. My tests works in way of doing some settings via CLI, deploy application, do the test, undeploy application, stop the server.
> During the stopping the server this exception is shown in log.
> Adding server log from my test for possible more details.
> [1]
> {code}
> INFO  [org.jboss.as.server] (Thread-3) WFLYSRV0220: Server shutdown has been requested.
> INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = module_ojdbc7.jar
> INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-1) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> INFO  [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 77) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Stopped Driver service with driver-name = h2
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0019: Host default-host stopping
> ERROR [org.xnio.listener] (XNIO-2 I/O-1) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 2d696007 rejected from org.xnio.XnioWorker$TaskPool at 74a153ee[Shutting down, pool size = 9, active threads = 0, queued tasks = 0, completed tasks = 50]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364)
> at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.channels.TranslatingSuspendableChannel.close(TranslatingSuspendableChannel.java:906)
> at org.xnio.IoUtils.safeClose(IoUtils.java:134)
> at org.xnio.channels.TranslatingSuspendableChannel$3.handleEvent(TranslatingSuspendableChannel.java:133)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.StreamConnection.invokeCloseListener(StreamConnection.java:80)
> at org.xnio.Connection.writeClosed(Connection.java:117)
> at org.xnio.nio.AbstractNioStreamConnection.writeClosed(AbstractNioStreamConnection.java:47)
> at org.xnio.nio.NioSocketConduit.terminateWrites(NioSocketConduit.java:181)
> at org.xnio.nio.NioSocketConduit.truncateWrites(NioSocketConduit.java:191)
> at org.xnio.conduits.ConduitStreamSinkChannel.close(ConduitStreamSinkChannel.java:186)
> at org.xnio.IoUtils.safeClose(IoUtils.java:134)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.forceTermination(WriteReadyHandler.java:57)
> at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:107)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:490)
> INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 71) AMQ151003: resource adaptor stopped
> INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.0.0 [8e39e2e6-1fc3-11e5-b5ab-adb038d9447d] stopped
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending
> INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032018: Destroying TransactionManagerService
> INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032014: Stopping transaction recovery manager
> DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-3) PeriodicRecovery: Mode <== TERMINATED
> DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-3) PeriodicRecovery: shutdown scan wait complete
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to localhost/127.0.0.1:8080
> INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.0.Beta2 stopping
> INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Alpha5) stopped in 237ms
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 21 10:58:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 21 Sep 2015 10:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.694.1442847480120@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110894#comment-13110894 ] 

Heiko Braun commented on WFCORE-994:
------------------------------------

IMO there are two issues here:

1. The first description (host="macbook-pro.fritz.box") is incomplete, it lacks the attributes, children, etc
2. The overall structure differs from what we usually see: a breakdown into /<resource>=* and it's exceptions

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 10:59:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 21 Sep 2015 10:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.698.1442847540268@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110894#comment-13110894 ] 

Heiko Braun edited comment on WFCORE-994 at 9/21/15 10:58 AM:
--------------------------------------------------------------

IMO there are two issues here:

1. The first description (host="macbook-pro.fritz.box") is incomplete, it lacks the attributes, children, etc
2. The overall structure differs from what we usually see: a breakdown into /<resource>=* and it's exceptions 


was (Author: heiko.braun):
IMO there are two issues here:

1. The first description (host="macbook-pro.fritz.box") is incomplete, it lacks the attributes, children, etc
2. The overall structure differs from what we usually see: a breakdown into /<resource>=* and it's exceptions

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 11:31:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Mon, 21 Sep 2015 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5236) [Migration operation] [Web to
 Undertow] SSL configuration - verify client attribute value is not properly
 migrated
In-Reply-To: <JIRA.12583201.1440978018000@Atlassian.JIRA>
References: <JIRA.12583201.1440978018000@Atlassian.JIRA>
	<JIRA.12583201.1440978018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583201.1440978018000.929.1442849460344@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka reopened WFLY-5236:
------------------------------------


Checked with WildFly 10.0.0.CR1.

Values {{true}} and {{false}} are not migrated even though according to {{jboss-as-web_2_2.xsd}}, {{true=require}} and {{false=none}}. As such these values should be migrated the same way as values {{require}} and {{none}}

> [Migration operation] [Web to Undertow] SSL configuration - verify client attribute value is not properly migrated
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5236
>                 URL: https://issues.jboss.org/browse/WFLY-5236
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2, 10.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> In web there exists different options for {{verify-client}} attribute of ssl configuration [1] than values which are allowed to be defined as part of https-listener (REQUIRED, REQUESTED, NOT_REQUESTED).
> Currently the migration operation fails as the value isn't converted to equivalent value accepted by Undertow.
> [1]
> {code:xml}
>  <xs:attribute name="verify-client" default="none">
>             <xs:annotation>
>                 <xs:documentation>
>                     that is OpenSSL SSLVerifyClient (optional,require,optionalNoCA,none) and clientAuth (true=require/false=none)
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 11:31:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Mon, 21 Sep 2015 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5236) [Migration operation] [Web to
 Undertow] SSL configuration - verify client attribute value is not properly
 migrated
In-Reply-To: <JIRA.12583201.1440978018000@Atlassian.JIRA>
References: <JIRA.12583201.1440978018000@Atlassian.JIRA>
	<JIRA.12583201.1440978018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583201.1440978018000.932.1442849460391@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-5236:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> [Migration operation] [Web to Undertow] SSL configuration - verify client attribute value is not properly migrated
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5236
>                 URL: https://issues.jboss.org/browse/WFLY-5236
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2, 10.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> In web there exists different options for {{verify-client}} attribute of ssl configuration [1] than values which are allowed to be defined as part of https-listener (REQUIRED, REQUESTED, NOT_REQUESTED).
> Currently the migration operation fails as the value isn't converted to equivalent value accepted by Undertow.
> [1]
> {code:xml}
>  <xs:attribute name="verify-client" default="none">
>             <xs:annotation>
>                 <xs:documentation>
>                     that is OpenSSL SSLVerifyClient (optional,require,optionalNoCA,none) and clientAuth (true=require/false=none)
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 11:43:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 21 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.962.1442850180271@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110894#comment-13110894 ] 

Heiko Braun edited comment on WFCORE-994 at 9/21/15 11:42 AM:
--------------------------------------------------------------

IMO there is one issues here:

The first description (host="macbook-pro.fritz.box") is incomplete, it lacks the attributes, children, etc



was (Author: heiko.braun):
IMO there are two issues here:

1. The first description (host="macbook-pro.fritz.box") is incomplete, it lacks the attributes, children, etc
2. The overall structure differs from what we usually see: a breakdown into /<resource>=* and it's exceptions 

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 11:43:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 21 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.966.1442850180331@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110894#comment-13110894 ] 

Heiko Braun edited comment on WFCORE-994 at 9/21/15 11:42 AM:
--------------------------------------------------------------

IMO there is one issues here:

The first description (host="macbook-pro.fritz.box") is incomplete, it lacks the access-control attributes, children, etc



was (Author: heiko.braun):
IMO there is one issues here:

The first description (host="macbook-pro.fritz.box") is incomplete, it lacks the attributes, children, etc


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 11:56:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 11:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.998.1442850960215@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-994:
------------------------------------
    Fix Version/s: 2.0.0.CR2


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR2
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 11:56:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 21 Sep 2015 11:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.1002.1442850960324@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFCORE-994:
-------------------------------
    Priority: Critical  (was: Major)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 11:59:00 2015
From: issues at jboss.org (Daniel Coughlin (JIRA))
Date: Mon, 21 Sep 2015 11:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1293) Broken Links on JBoss.org &
 developers.redhat.com
In-Reply-To: <JIRA.12585550.1442851093000@Atlassian.JIRA>
References: <JIRA.12585550.1442851093000@Atlassian.JIRA>
	<JIRA.12585550.1442851093139@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585550.1442851093000.1020.1442851140129@Atlassian.JIRA>

Daniel Coughlin created JBJCA-1293:
--------------------------------------

             Summary: Broken Links on JBoss.org & developers.redhat.com
                 Key: JBJCA-1293
                 URL: https://issues.jboss.org/browse/JBJCA-1293
             Project: IronJacamar
          Issue Type: Bug
            Reporter: Daniel Coughlin
            Assignee: Jesper Pedersen


The following broken link is currently listed against this project on developers.redhat.com/projects.

http://fisheye.jboss.com/browse/JBossAS/projects/jboss-jca/trunk/

If you maintain a project.properties file that you have told the RHD team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 12:16:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Mon, 21 Sep 2015 12:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.1082.1442852160101@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110940#comment-13110940 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

Paul,

This has always worked in previous releases.  If this is no longer the options to use, then where can I find an example of the replacement options?

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 13:01:00 2015
From: issues at jboss.org (Jano Peti (JIRA))
Date: Mon, 21 Sep 2015 13:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.1205.1442854860223@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110957#comment-13110957 ] 

Jano Peti commented on WFLY-3990:
---------------------------------

I have only 255 entries.
mes.invokeAll(List<Callable>...)

Mac OS 10.10.5

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

{code}
18:35:17,269 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /mqtt2ws/web/start.xhtml: javax.servlet.ServletException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:667)
	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: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:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.ejb.EJBTransactionRolledbackException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
	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.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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$$$view2.findIpAddressesWithOpenPort(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$Proxy$_$$_Weld$EnterpriseProxy$.findIpAddressesWithOpenPort(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.BrokerService.scanAndAddFoundBrokers(BrokerService.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.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.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:102)
	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)
	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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.BrokerService$$$view6.scanAndAddFoundBrokers(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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 sk.mito.jp.iot.mqtt2ws.BrokerService$Proxy$_$$_Weld$EnterpriseProxy$.scanAndAddFoundBrokers(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.web.BrokerDashboard.scanAndAddFoundBrokers(BrokerDashboard.java:132)
	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 javax.el.ELUtil.invokeMethod(ELUtil.java:308)
	at javax.el.BeanELResolver.invoke(BeanELResolver.java:537)
	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
	at com.sun.el.parser.AstValue.invoke(AstValue.java:286)
	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
	at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:147)
	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:813)
	at javax.faces.component.UICommand.broadcast(UICommand.java:300)
	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:654)
	... 32 more
Caused by: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.executeManagedFutureTask(AbstractManagedExecutorService.java:402)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.invokeAll(AbstractManagedExecutorService.java:245)
	at org.glassfish.enterprise.concurrent.ManagedExecutorServiceAdapter.invokeAll(ManagedExecutorServiceAdapter.java:77)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService.findIpAddressesWithOpenPort(BrokerFinderService.java:43)
	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.invokeInCallerTx(CMTTxInterceptor.java:254)
	... 173 more
{code]

> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 13:02:00 2015
From: issues at jboss.org (Jano Peti (JIRA))
Date: Mon, 21 Sep 2015 13:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.1212.1442854920376@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110957#comment-13110957 ] 

Jano Peti edited comment on WFLY-3990 at 9/21/15 1:01 PM:
----------------------------------------------------------

I have only 255 entries.
mes.invokeAll(List<Callable>...)

Mac OS 10.10.5

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

{code}
18:35:17,269 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /mqtt2ws/web/start.xhtml: javax.servlet.ServletException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:667)
	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: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:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.ejb.EJBTransactionRolledbackException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
	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.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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$$$view2.findIpAddressesWithOpenPort(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$Proxy$_$$_Weld$EnterpriseProxy$.findIpAddressesWithOpenPort(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.BrokerService.scanAndAddFoundBrokers(BrokerService.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.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.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:102)
	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)
	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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.BrokerService$$$view6.scanAndAddFoundBrokers(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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 sk.mito.jp.iot.mqtt2ws.BrokerService$Proxy$_$$_Weld$EnterpriseProxy$.scanAndAddFoundBrokers(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.web.BrokerDashboard.scanAndAddFoundBrokers(BrokerDashboard.java:132)
	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 javax.el.ELUtil.invokeMethod(ELUtil.java:308)
	at javax.el.BeanELResolver.invoke(BeanELResolver.java:537)
	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
	at com.sun.el.parser.AstValue.invoke(AstValue.java:286)
	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
	at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:147)
	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:813)
	at javax.faces.component.UICommand.broadcast(UICommand.java:300)
	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:654)
	... 32 more
Caused by: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.executeManagedFutureTask(AbstractManagedExecutorService.java:402)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.invokeAll(AbstractManagedExecutorService.java:245)
	at org.glassfish.enterprise.concurrent.ManagedExecutorServiceAdapter.invokeAll(ManagedExecutorServiceAdapter.java:77)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService.findIpAddressesWithOpenPort(BrokerFinderService.java:43)
	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.invokeInCallerTx(CMTTxInterceptor.java:254)
	... 173 more
{code}


was (Author: janci_peti):
I have only 255 entries.
mes.invokeAll(List<Callable>...)

Mac OS 10.10.5

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

{code}
18:35:17,269 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /mqtt2ws/web/start.xhtml: javax.servlet.ServletException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:667)
	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: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:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.ejb.EJBTransactionRolledbackException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
	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.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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$$$view2.findIpAddressesWithOpenPort(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$Proxy$_$$_Weld$EnterpriseProxy$.findIpAddressesWithOpenPort(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.BrokerService.scanAndAddFoundBrokers(BrokerService.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.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.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:102)
	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)
	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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.BrokerService$$$view6.scanAndAddFoundBrokers(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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 sk.mito.jp.iot.mqtt2ws.BrokerService$Proxy$_$$_Weld$EnterpriseProxy$.scanAndAddFoundBrokers(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.web.BrokerDashboard.scanAndAddFoundBrokers(BrokerDashboard.java:132)
	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 javax.el.ELUtil.invokeMethod(ELUtil.java:308)
	at javax.el.BeanELResolver.invoke(BeanELResolver.java:537)
	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
	at com.sun.el.parser.AstValue.invoke(AstValue.java:286)
	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
	at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:147)
	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:813)
	at javax.faces.component.UICommand.broadcast(UICommand.java:300)
	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:654)
	... 32 more
Caused by: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.executeManagedFutureTask(AbstractManagedExecutorService.java:402)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.invokeAll(AbstractManagedExecutorService.java:245)
	at org.glassfish.enterprise.concurrent.ManagedExecutorServiceAdapter.invokeAll(ManagedExecutorServiceAdapter.java:77)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService.findIpAddressesWithOpenPort(BrokerFinderService.java:43)
	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.invokeInCallerTx(CMTTxInterceptor.java:254)
	... 173 more
{code]

> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 13:05:00 2015
From: issues at jboss.org (Michael Reynolds (JIRA))
Date: Mon, 21 Sep 2015 13:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-912) Add ability to enable the
 audit log from the Command interface
In-Reply-To: <JIRA.12584640.1441950283000@Atlassian.JIRA>
References: <JIRA.12584640.1441950283000@Atlassian.JIRA>
	<JIRA.12584640.1441950283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584640.1441950283000.1239.1442855100602@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Reynolds closed DROOLS-912.
-----------------------------------
    Resolution: Done


> Add ability to enable the audit log from the Command interface
> --------------------------------------------------------------
>
>                 Key: DROOLS-912
>                 URL: https://issues.jboss.org/browse/DROOLS-912
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>            Reporter: Michael Reynolds
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Implement the ability to enable the audit log from the Command API in drools-core.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 13:13:00 2015
From: issues at jboss.org (Jano Peti (JIRA))
Date: Mon, 21 Sep 2015 13:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.1264.1442855580233@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110957#comment-13110957 ] 

Jano Peti edited comment on WFLY-3990 at 9/21/15 1:12 PM:
----------------------------------------------------------

I have only 255 entries.
mes.invokeAll(List<Callable>...)

Mac OS 10.10.5
Wildfly 9.0.1
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

{code}
18:35:17,269 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /mqtt2ws/web/start.xhtml: javax.servlet.ServletException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:667)
	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: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:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.ejb.EJBTransactionRolledbackException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
	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.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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$$$view2.findIpAddressesWithOpenPort(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$Proxy$_$$_Weld$EnterpriseProxy$.findIpAddressesWithOpenPort(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.BrokerService.scanAndAddFoundBrokers(BrokerService.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.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.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:102)
	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)
	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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.BrokerService$$$view6.scanAndAddFoundBrokers(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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 sk.mito.jp.iot.mqtt2ws.BrokerService$Proxy$_$$_Weld$EnterpriseProxy$.scanAndAddFoundBrokers(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.web.BrokerDashboard.scanAndAddFoundBrokers(BrokerDashboard.java:132)
	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 javax.el.ELUtil.invokeMethod(ELUtil.java:308)
	at javax.el.BeanELResolver.invoke(BeanELResolver.java:537)
	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
	at com.sun.el.parser.AstValue.invoke(AstValue.java:286)
	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
	at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:147)
	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:813)
	at javax.faces.component.UICommand.broadcast(UICommand.java:300)
	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:654)
	... 32 more
Caused by: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.executeManagedFutureTask(AbstractManagedExecutorService.java:402)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.invokeAll(AbstractManagedExecutorService.java:245)
	at org.glassfish.enterprise.concurrent.ManagedExecutorServiceAdapter.invokeAll(ManagedExecutorServiceAdapter.java:77)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService.findIpAddressesWithOpenPort(BrokerFinderService.java:43)
	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.invokeInCallerTx(CMTTxInterceptor.java:254)
	... 173 more
{code}


was (Author: janci_peti):
I have only 255 entries.
mes.invokeAll(List<Callable>...)

Mac OS 10.10.5

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

{code}
18:35:17,269 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /mqtt2ws/web/start.xhtml: javax.servlet.ServletException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:667)
	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: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:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.ejb.EJBTransactionRolledbackException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
	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.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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$$$view2.findIpAddressesWithOpenPort(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService$Proxy$_$$_Weld$EnterpriseProxy$.findIpAddressesWithOpenPort(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.BrokerService.scanAndAddFoundBrokers(BrokerService.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.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.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:102)
	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)
	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:634)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at sk.mito.jp.iot.mqtt2ws.BrokerService$$$view6.scanAndAddFoundBrokers(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
	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 sk.mito.jp.iot.mqtt2ws.BrokerService$Proxy$_$$_Weld$EnterpriseProxy$.scanAndAddFoundBrokers(Unknown Source)
	at sk.mito.jp.iot.mqtt2ws.web.BrokerDashboard.scanAndAddFoundBrokers(BrokerDashboard.java:132)
	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 javax.el.ELUtil.invokeMethod(ELUtil.java:308)
	at javax.el.BeanELResolver.invoke(BeanELResolver.java:537)
	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
	at com.sun.el.parser.AstValue.invoke(AstValue.java:286)
	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
	at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:147)
	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:813)
	at javax.faces.component.UICommand.broadcast(UICommand.java:300)
	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:654)
	... 32 more
Caused by: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 717ba1f rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 5e3ffa4a[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 29]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.executeManagedFutureTask(AbstractManagedExecutorService.java:402)
	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.invokeAll(AbstractManagedExecutorService.java:245)
	at org.glassfish.enterprise.concurrent.ManagedExecutorServiceAdapter.invokeAll(ManagedExecutorServiceAdapter.java:77)
	at sk.mito.jp.iot.mqtt2ws.portscan.BrokerFinderService.findIpAddressesWithOpenPort(BrokerFinderService.java:43)
	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.invokeInCallerTx(CMTTxInterceptor.java:254)
	... 173 more
{code}

> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 13:22:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 13:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-986) Add-user script should
 reject weak passwords
In-Reply-To: <JIRA.12585195.1442481956000@Atlassian.JIRA>
References: <JIRA.12585195.1442481956000@Atlassian.JIRA>
	<JIRA.12585195.1442481956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585195.1442481956000.1279.1442856120279@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-986:
-------------------------------
    Component/s: Security
                     (was: Scripts)


> Add-user script should reject weak passwords
> --------------------------------------------
>
>                 Key: WFCORE-986
>                 URL: https://issues.jboss.org/browse/WFCORE-986
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> *Description of problem:*
> Add-user script should reject weak passwords. Users should use stronger passwords to improve security. Restriction of password should be same as in EAP 6.4.x.
> * Restriction policy is defined in jboss-eap-7.0/bin/add-user.properties
> ** {{password.restriction=WARN}} should be replaced by {{password.restriction=REJECT}}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./add-user.sh -u ccc -p ddd -s
> *Actual results:*
> No error.
> *Expected results:*
> {noformat}WFLYDM0053: Password must have at least 8 characters!{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 21 13:22:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 13:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-986) Add-user script should
 reject weak passwords
In-Reply-To: <JIRA.12585195.1442481956000@Atlassian.JIRA>
References: <JIRA.12585195.1442481956000@Atlassian.JIRA>
	<JIRA.12585195.1442481956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585195.1442481956000.1285.1442856120415@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFCORE-986:
----------------------------------

    Assignee: Darran Lofthouse  (was: Tomaz Cerar)


> Add-user script should reject weak passwords
> --------------------------------------------
>
>                 Key: WFCORE-986
>                 URL: https://issues.jboss.org/browse/WFCORE-986
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Marek Kopeck?
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> *Description of problem:*
> Add-user script should reject weak passwords. Users should use stronger passwords to improve security. Restriction of password should be same as in EAP 6.4.x.
> * Restriction policy is defined in jboss-eap-7.0/bin/add-user.properties
> ** {{password.restriction=WARN}} should be replaced by {{password.restriction=REJECT}}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./add-user.sh -u ccc -p ddd -s
> *Actual results:*
> No error.
> *Expected results:*
> {noformat}WFLYDM0053: Password must have at least 8 characters!{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 21 13:25:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 21 Sep 2015 13:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-986) Add-user script should
 reject weak passwords
In-Reply-To: <JIRA.12585195.1442481956000@Atlassian.JIRA>
References: <JIRA.12585195.1442481956000@Atlassian.JIRA>
	<JIRA.12585195.1442481956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585195.1442481956000.1299.1442856300474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-986.
-------------------------------------
    Fix Version/s: 2.0.0.CR2
       Resolution: Rejected


Current behaviour is as requested by [~jason.greene]

> Add-user script should reject weak passwords
> --------------------------------------------
>
>                 Key: WFCORE-986
>                 URL: https://issues.jboss.org/browse/WFCORE-986
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Marek Kopeck?
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> *Description of problem:*
> Add-user script should reject weak passwords. Users should use stronger passwords to improve security. Restriction of password should be same as in EAP 6.4.x.
> * Restriction policy is defined in jboss-eap-7.0/bin/add-user.properties
> ** {{password.restriction=WARN}} should be replaced by {{password.restriction=REJECT}}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./add-user.sh -u ccc -p ddd -s
> *Actual results:*
> No error.
> *Expected results:*
> {noformat}WFLYDM0053: Password must have at least 8 characters!{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 21 13:29:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 21 Sep 2015 13:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-916) Add an async servlet to
	the toolkit
In-Reply-To: <JIRA.12585572.1442856490000@Atlassian.JIRA>
References: <JIRA.12585572.1442856490000@Atlassian.JIRA>
	<JIRA.12585572.1442856490504@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585572.1442856490000.1345.1442856540183@Atlassian.JIRA>

Darran Lofthouse created SECURITY-916:
-----------------------------------------

             Summary: Add an async servlet to the toolkit
                 Key: SECURITY-916
                 URL: https://issues.jboss.org/browse/SECURITY-916
             Project: PicketBox 
          Issue Type: Sub-task
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_3_0_0_Final


The purpose of this is to verify we are delegating in the async case as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:14:00 2015
From: issues at jboss.org (The Alchemist (JIRA))
Date: Mon, 21 Sep 2015 14:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in
 Wildfly Web Admin Console under "Configuration" tab
In-Reply-To: <JIRA.12585575.1442859212000@Atlassian.JIRA>
References: <JIRA.12585575.1442859212000@Atlassian.JIRA>
	<JIRA.12585575.1442859212308@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585575.1442859212000.1399.1442859240155@Atlassian.JIRA>

The Alchemist created WFLY-5376:
-----------------------------------

             Summary: poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab
                 Key: WFLY-5376
                 URL: https://issues.jboss.org/browse/WFLY-5376
             Project: WildFly
          Issue Type: Enhancement
          Components: Web Console
    Affects Versions: 10.0.0.CR1
            Reporter: The Alchemist
            Assignee: Heiko Braun
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:14:00 2015
From: issues at jboss.org (The Alchemist (JIRA))
Date: Mon, 21 Sep 2015 14:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in
 Wildfly Web Admin Console under "Configuration" tab
In-Reply-To: <JIRA.12585575.1442859212000@Atlassian.JIRA>
References: <JIRA.12585575.1442859212000@Atlassian.JIRA>
	<JIRA.12585575.1442859212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585575.1442859212000.1402.1442859240214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

The Alchemist updated WFLY-5376:
--------------------------------
    Attachment: screenshot-1.png


> poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5376
>                 URL: https://issues.jboss.org/browse/WFLY-5376
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.0.0.CR1
>            Reporter: The Alchemist
>            Assignee: Heiko Braun
>            Priority: Minor
>         Attachments: screenshot-1.png
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:15:01 2015
From: issues at jboss.org (The Alchemist (JIRA))
Date: Mon, 21 Sep 2015 14:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in
 Wildfly Web Admin Console under "Configuration" tab
In-Reply-To: <JIRA.12585575.1442859212000@Atlassian.JIRA>
References: <JIRA.12585575.1442859212000@Atlassian.JIRA>
	<JIRA.12585575.1442859212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585575.1442859212000.1405.1442859301020@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

The Alchemist updated WFLY-5376:
--------------------------------
    Description: !!screenshot-1.png!


> poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5376
>                 URL: https://issues.jboss.org/browse/WFLY-5376
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.0.0.CR1
>            Reporter: The Alchemist
>            Assignee: Heiko Braun
>            Priority: Minor
>         Attachments: screenshot-1.png
>
>
> !!screenshot-1.png!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:15:02 2015
From: issues at jboss.org (The Alchemist (JIRA))
Date: Mon, 21 Sep 2015 14:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in
 Wildfly Web Admin Console under "Configuration" tab
In-Reply-To: <JIRA.12585575.1442859212000@Atlassian.JIRA>
References: <JIRA.12585575.1442859212000@Atlassian.JIRA>
	<JIRA.12585575.1442859212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585575.1442859212000.1408.1442859302007@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

The Alchemist updated WFLY-5376:
--------------------------------
    Description: 
h2. Screenshot

!screenshot-1.png!

h2. Specs
* Mac OS X 10.10.5
* MacBook Pro (Retina, 15-inch, Late 2013)
* Chrome  45.0.2454.93 (64-bit)

  was:!!screenshot-1.png!



> poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5376
>                 URL: https://issues.jboss.org/browse/WFLY-5376
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.0.0.CR1
>            Reporter: The Alchemist
>            Assignee: Heiko Braun
>            Priority: Minor
>         Attachments: screenshot-1.png
>
>
> h2. Screenshot
> !screenshot-1.png!
> h2. Specs
> * Mac OS X 10.10.5
> * MacBook Pro (Retina, 15-inch, Late 2013)
> * Chrome  45.0.2454.93 (64-bit)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:30:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Mon, 21 Sep 2015 14:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in
 Wildfly Web Admin Console under "Configuration" tab
In-Reply-To: <JIRA.12585575.1442859212000@Atlassian.JIRA>
References: <JIRA.12585575.1442859212000@Atlassian.JIRA>
	<JIRA.12585575.1442859212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585575.1442859212000.1444.1442860200275@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110993#comment-13110993 ] 

Heiko Braun commented on WFLY-5376:
-----------------------------------

Try to clean the browser cache. I assume it happens when moving into a more recent Wildfly version?

> poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5376
>                 URL: https://issues.jboss.org/browse/WFLY-5376
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.0.0.CR1
>            Reporter: The Alchemist
>            Assignee: Heiko Braun
>            Priority: Minor
>         Attachments: screenshot-1.png
>
>
> h2. Screenshot
> !screenshot-1.png!
> h2. Specs
> * Mac OS X 10.10.5
> * MacBook Pro (Retina, 15-inch, Late 2013)
> * Chrome  45.0.2454.93 (64-bit)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:57:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 14:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-981)
 RemoteDomainConnectionService uses out of date HostInfo data when
 reconnecting
In-Reply-To: <JIRA.12585033.1442365330000@Atlassian.JIRA>
References: <JIRA.12585033.1442365330000@Atlassian.JIRA>
	<JIRA.12585033.1442365330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585033.1442365330000.1505.1442861820108@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-981:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1091  (was: https://github.com/wildfly/wildfly-core/pull/1083)


> RemoteDomainConnectionService uses out of date HostInfo data when reconnecting
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-981
>                 URL: https://issues.jboss.org/browse/WFCORE-981
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta7
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When RemoteDomainConnectionService starts, it calculates a "hostInfo" ModelNode that among other things includes data about what addresses the host is ignoring, and what server groups and socket binding groups are relevant to it if it is ignoring resources unrelated to its servers.
> Problem is, this data is never updated if the host's config changes, so if the host needs to reconnect to the master, it sends out-of-date data to the master, and also uses out of date data to process the info that comes back from the master.
> We need to figure out how to refresh that data for each connection to the master.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:58:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 14:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-310) Don't copy the contents to
 all hosts when assigning a deployment to a server-group
In-Reply-To: <JIRA.12534883.1394713780000@Atlassian.JIRA>
References: <JIRA.12534883.1394713780000@Atlassian.JIRA>
	<JIRA.12534883.1394713780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534883.1394713780000.1512.1442861880224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-310:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1091  (was: https://github.com/wildfly/wildfly-core/pull/1083)


> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-310
>                 URL: https://issues.jboss.org/browse/WFCORE-310
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Ken Wills
>            Priority: Blocker
>             Fix For: 2.0.0.CR2
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 14:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.1515.1442861940237@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-992:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1090


> Memory leak in host controller
> ------------------------------
>
>                 Key: WFCORE-992
>                 URL: https://issues.jboss.org/browse/WFCORE-992
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:
> {code}
> cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
> mvn clean install -DskipTests
> cd testsuite/domain
> mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
> {code}
> After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:
> {code}
> 2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
> 2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
> 2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
> 2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
> 2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
> 2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
> {code}
> Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 14:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-992) Memory leak in host
	controller
In-Reply-To: <JIRA.12585478.1442832077000@Atlassian.JIRA>
References: <JIRA.12585478.1442832077000@Atlassian.JIRA>
	<JIRA.12585478.1442832077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585478.1442832077000.1518.1442861940286@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-992:
---------------------------------------

    Assignee: Ladislav Thon  (was: Brian Stansberry)


> Memory leak in host controller
> ------------------------------
>
>                 Key: WFCORE-992
>                 URL: https://issues.jboss.org/browse/WFCORE-992
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> The {{ManagedServerProxy}} class in the {{host-controller}} module contains a memory leak, which can be easily reproduced using the RBAC soak test, like so:
> {code}
> cd wildfly-core # checkout WildFly Core 2.0.0.CR1, which is in WildFly 10.0.0.CR1, or current master
> mvn clean install -DskipTests
> cd testsuite/domain
> mvn clean test -Dts.noSmoke -Dts.domain -Prbac-soak -Djboss.test.rbac.soak.clients=100 -Djboss.test.rbac.soak.iterations=50
> {code}
> After acquiring a heap dump ({{-XX:+HeapDumpOnOutOfMemoryError}}), it's clear that out of the 512 MB of heap space a host controller has, more than 400 MB is taken by a single instance of the {{ManagedServerProxy}} class, specifically by its {{activeRequests}} field. This {{Map}} has a single entry whose value is a {{Set}} of "pending" futures. I added a couple of debug prints to the places where this {{Set}} is modified, only to see this:
> {code}
> 2015-09-21 12:32:00,704 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 142a1c24
> 2015-09-21 12:32:00,707 INFO  [stdout] (Remoting "master:MANAGEMENT" task-3) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 5bfbf423
> 2015-09-21 12:32:00,707 INFO  [stdout] (management-handler-thread - 4) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 27e2e96c
> 2015-09-21 12:32:00,708 INFO  [stdout] (Remoting "master:MANAGEMENT" task-2) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 72817a0d
> 2015-09-21 12:32:00,713 INFO  [stdout] (management-handler-thread - 2) !!! added org.jboss.as.controller.remote.TransactionalProtocolClientImpl$1 at 73d373a7
> 2015-09-21 12:32:00,718 INFO  [stdout] (Remoting "master:MANAGEMENT" task-9) !!! removed org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl at 20bd6db1
> {code}
> Skipping a few intermediate steps, the root cause is that {{AbstractDelegatingAsyncFuture}} delegates {{addListener}} directly to an underlying future, so the callbacks don't get the original instance, but the underlying one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 14:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 14:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.1521.1442861940335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-909:
------------------------------------
    Priority: Minor  (was: Major)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 15:00:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 15:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.1524.1442862000334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-909:
------------------------------------
        Parent:     (was: WFCORE-901)
    Issue Type: Task  (was: Sub-task)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0.CR2
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 15:13:00 2015
From: issues at jboss.org (Pokpitch Patcharadamrongkul (JIRA))
Date: Mon, 21 Sep 2015 15:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-925) Cannot deploy kie-server to
 Wildfly 10.0.0.CR1
In-Reply-To: <JIRA.12585580.1442862774000@Atlassian.JIRA>
References: <JIRA.12585580.1442862774000@Atlassian.JIRA>
	<JIRA.12585580.1442862774883@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585580.1442862774000.1532.1442862780166@Atlassian.JIRA>

Pokpitch Patcharadamrongkul created DROOLS-925:
--------------------------------------------------

             Summary: Cannot deploy kie-server to Wildfly 10.0.0.CR1
                 Key: DROOLS-925
                 URL: https://issues.jboss.org/browse/DROOLS-925
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 6.3.0.CR2
         Environment: Wildfly 10.0.0.CR1
            Reporter: Pokpitch Patcharadamrongkul
            Assignee: Edson Tirelli
            Priority: Critical
             Fix For: 6.3.0.Final


Cannot deploy kie-server to Wildfly 10.0.0.CR1 (HornetQ is to be deprecated from Wildfly 10.x.x) Please fixed in kie-server-x.x-x.war/META-INF/kie-server-jms.xml

{color:red}Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /opt/wildfly-10.0.0.CR1/standalone/tmp/vfs/temp/temp8eb8a1f894857057/content-c7b7cd6a0a56658e/META-INF/kie-server-jms.xml
	at org.wildfly.extension.messaging.activemq.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95)
	... 6 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108)
	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
	at org.wildfly.extension.messaging.activemq.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89)
	... 6 more{color}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 15:26:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Sep 2015 15:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-995) Add possibility to enable
 debug mode by setting environment variable in standalone scripts
In-Reply-To: <JIRA.12585582.1442863498000@Atlassian.JIRA>
References: <JIRA.12585582.1442863498000@Atlassian.JIRA>
	<JIRA.12585582.1442863498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585582.1442863498000.1560.1442863560359@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-1124 to WFCORE-995:
-------------------------------------------

        Project: WildFly Core  (was: JBoss Enterprise Application Platform)
            Key: WFCORE-995  (was: JBEAP-1124)
       Workflow: GIT Pull Request workflow   (was: CDW v1)
    Component/s: Scripts
                     (was: Scripts)


> Add possibility to enable debug mode by setting environment variable in standalone scripts
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-995
>                 URL: https://issues.jboss.org/browse/WFCORE-995
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> It's common practice in Docker to control image run by configuring environment variables.
> E.g.
> {code:bash}
> docker run -e POSTGRES_PASSWORD=mysecretpassword -d postgres
> {code}
> The Cloud Enablement team adds such a possibility to EAP docker images. They [replaces|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-dockerfiles/blob/0a22b6ef7dff7855288f32c55dd122b47cad66ff/standalone/eap/6.4/scripts/install_as_root] initial value of {{DEBUG_MODE}}:
> {code:bash}
> # Enhance standalone.sh to make remote JAVA debugging possible by specifying
> # DEBUG=true environment variable
> sed -i 's|DEBUG_MODE=false|DEBUG_MODE="${DEBUG:-false}"|' $JBOSS_HOME/bin/standalone.sh
> {code}
> It's not a clean solution. This change should be made in original scripts and not on a Dockerfile level. 
> Please allow configuring the {{DEBUG_MODE}} from environment variables (in similar as e.g. the {{JAVA_OPTS}} are handled.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 15:36:00 2015
From: issues at jboss.org (The Alchemist (JIRA))
Date: Mon, 21 Sep 2015 15:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in
 Wildfly Web Admin Console under "Configuration" tab
In-Reply-To: <JIRA.12585575.1442859212000@Atlassian.JIRA>
References: <JIRA.12585575.1442859212000@Atlassian.JIRA>
	<JIRA.12585575.1442859212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585575.1442859212000.1575.1442864160141@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111011#comment-13111011 ] 

The Alchemist commented on WFLY-5376:
-------------------------------------

@[~heiko.braun]: Thanks for the quick response.  I'm using multiple Wildfly versions simultaneously as we test against them.  I'll give cleaning the browser cache when I get a chance.

> poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5376
>                 URL: https://issues.jboss.org/browse/WFLY-5376
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.0.0.CR1
>            Reporter: The Alchemist
>            Assignee: Heiko Braun
>            Priority: Minor
>         Attachments: screenshot-1.png
>
>
> h2. Screenshot
> !screenshot-1.png!
> h2. Specs
> * Mac OS X 10.10.5
> * MacBook Pro (Retina, 15-inch, Late 2013)
> * Chrome  45.0.2454.93 (64-bit)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.1773.1442869860891@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-994:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-989) Premature registration of
 reconnecting server
In-Reply-To: <JIRA.12585427.1442632267000@Atlassian.JIRA>
References: <JIRA.12585427.1442632267000@Atlassian.JIRA>
	<JIRA.12585427.1442632267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585427.1442632267000.1775.1442869860923@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-989:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> Premature registration of reconnecting server
> ---------------------------------------------
>
>                 Key: WFCORE-989
>                 URL: https://issues.jboss.org/browse/WFCORE-989
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR3
>
>
> ServerInventoryImpl.reconnectServer is registering the ProxyController for the reconnecting server with the DomainModelControllerService. The problem is that ProxyController is not yet in a state where it can forward requests to the server. That won't happen until the server calls back with a DomainServerProtocol.SERVER_RECONNECT_REQUEST and the ServerToHostProtocolHandler.ServerReconnectRequestHandler handles it. The effect is if a request for the server comes in during this window, it will fail. If that request is part of a domain operation rollout (because during the window the HC regarded the server as 'live' and instructed the DC to send rollout ops to it), then the domain rollout will be affected. This happened in the testsuite failure I just saw. Most significant logging is as follows:
> {code}
> 2015-09-18 17:59:32,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" (Host Controller) started in 93ms - Started 48 of 51 services (15 services are lazy, passive or on-demand)
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-16) Initialized for 1849055188
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-14) WFLYHC0021: Server [Server:main-three] connected using connection [Channel ID 08aa200b (inbound) of Remoting connection 27e3d90d to /127.0.0.1:49272]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-15) WFLYHC0021: Server [Server:other-two] connected using connection [Channel ID 02bd2646 (inbound) of Remoting connection 64a8b7f2 to /127.0.0.1:49273]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) Initialized for 1849055188
> 2015-09-18 17:59:32,252 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) sending prepared response for 1849055188  --- interrupted: false
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 481103151
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) Initialized for 481103151
> 2015-09-18 17:59:32,255 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) sending pre-prepare failed response for 1933145457  --- interrupted: false
> 2015-09-18 17:59:32,256 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) sending pre-prepare failed response for 481103151  --- interrupted: false
> {code}
> The HC completes boot. Then servers main-three and other-two register. The HC sends a prepared response to a request. This is the host rollout request to the slave from the DC with the response being the ops to invoke on the servers. The HC reports sending a "pre-prepare failed response" to two requests. These are the requests the DC has asked it to proxy to the servers.
> The result of all this for the client is the following failure of a management op:
> {code}
> Failed operation:
> {
>     "operation" => "add",
>     "address" => [("extension" => "org.jboss.as.test.hc.extension")]
> }
> Response:
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"slave" => {"main-three" => "WFLYHC0153: Channel closed"}}},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => "WFLYHC0153: Channel closed"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {
>             "master" => {"main-one" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => [("HC" => "1.1.1")],
>                 "rolled-back" => true
>             }}},
>             "slave" => {"main-three" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => undefined,
>                 "failure-description" => "WFLYHC0153: Channel closed",
>                 "rolled-back" => true
>             }}}
>         }},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYHC0153: Channel closed",
>             "rolled-back" => true
>         }}}}}
>     }
> }
> {code}
> The "WFLYHC0153: Channel closed" failure is what is produced when an attempt is made to invoke on a disconnected proxy controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.1779.1442869860988@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-988:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR3
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.1782.1442869861039@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-979:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
>                 Key: WFCORE-979
>                 URL: https://issues.jboss.org/browse/WFCORE-979
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR3
>
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
>  testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >  
> >      <domain-controller>
> >          <!-- Remote domain controller configuration with a host and port -->
> > -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-937) --std-out=discard for
 embedded host controller doesn't work
In-Reply-To: <JIRA.12583210.1441006072000@Atlassian.JIRA>
References: <JIRA.12583210.1441006072000@Atlassian.JIRA>
	<JIRA.12583210.1441006072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583210.1441006072000.1786.1442869861151@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-937:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> --std-out=discard for embedded host controller doesn't work
> -----------------------------------------------------------
>
>                 Key: WFCORE-937
>                 URL: https://issues.jboss.org/browse/WFCORE-937
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR3
>
>
> Embedded host controller always prints the logs to the console no matter which --std-out= value I choose.
> {noformat}
> [disconnected /] embed-host-controller --std-out=discard
> 09:22:06,627 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.3.Final
> 09:22:06,733 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
> 09:22:06,758 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 09:22:07,769 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,799 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,824 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,843 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:08,067 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) (Host Controller) started in 1353ms - Started 25 of 27 services (8 services are lazy, passive or on-demand)
> [domain at embedded /] stop-embedded-host-controller 
> 09:22:15,926 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 5ms
> [disconnected /] exit 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-932) stop-embedded-server stops
 the embedded host controller and vice versa
In-Reply-To: <JIRA.12583124.1440765129000@Atlassian.JIRA>
References: <JIRA.12583124.1440765129000@Atlassian.JIRA>
	<JIRA.12583124.1440765129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583124.1440765129000.1790.1442869861265@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-932:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> stop-embedded-server stops the embedded host controller and vice versa
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-932
>                 URL: https://issues.jboss.org/browse/WFCORE-932
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>             Fix For: 2.0.0.CR3
>
>
> We have four new commands for controlling the lifecycle of embedded instances:
> * *embed-server* - launch embedded standalone
> * *stop-embedded-server* - stop embedded standalone
> * *embed-host-controller* - launch embedded host
> * *stop-embedded-host-controller* - stop embedded host
> \\
> I am able stop embedded standalone by *stop-embedded-host-controller* and embedded host controller by *stop-embedded-server*.
> {noformat}
> [disconnected /] embed-server 
> [standalone at embedded /] stop-embedded-host-controller 
> [disconnected /] embed-host-controller 
> 14:22:18,781 INFO  [org.jboss.modules] (AeshProcess: 15) JBoss Modules version 1.4.3.Final
> [domain at embedded /] stop-embedded-server 
> [disconnected /]
> {noformat}
> \\
> A question comes to my mind, do we need two commands for stopping the embedded instance?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.1795.1442869861360@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-931:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR3
>
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.1798.1442869861410@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-909:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0.CR3
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.1804.1442869861523@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-756:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 17:11:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 17:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.1806.1442869861567@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-628:
------------------------------------
    Fix Version/s: 2.0.0.CR3
                       (was: 2.0.0.CR2)


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 19:18:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 21 Sep 2015 19:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.2021.1442877480219@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111057#comment-13111057 ] 

David Lloyd commented on WFCORE-756:
------------------------------------

This should be highly mitigated by https://github.com/wildfly/wildfly-core/pull/1096 however there is a slight chance that these messages can appear in rare cases involving SSL.  Overall the occurrence should be greatly reduced with this PR.  Investigation continues, but we could potentially revisit the severity of the issue if things look OK.

> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 19:45:00 2015
From: issues at jboss.org (Renan Galang (JIRA))
Date: Mon, 21 Sep 2015 19:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.2053.1442879100149@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111058#comment-13111058 ] 

Renan Galang commented on WFCORE-715:
-------------------------------------

JDK 8 - I indicated the testing platforms and other thirdparty versions in the "Environment" field above. 

> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Tomaz Cerar
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.2091.1442883000674@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-994:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR4
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-989) Premature registration of
 reconnecting server
In-Reply-To: <JIRA.12585427.1442632267000@Atlassian.JIRA>
References: <JIRA.12585427.1442632267000@Atlassian.JIRA>
	<JIRA.12585427.1442632267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585427.1442632267000.2093.1442883000839@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-989:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> Premature registration of reconnecting server
> ---------------------------------------------
>
>                 Key: WFCORE-989
>                 URL: https://issues.jboss.org/browse/WFCORE-989
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> ServerInventoryImpl.reconnectServer is registering the ProxyController for the reconnecting server with the DomainModelControllerService. The problem is that ProxyController is not yet in a state where it can forward requests to the server. That won't happen until the server calls back with a DomainServerProtocol.SERVER_RECONNECT_REQUEST and the ServerToHostProtocolHandler.ServerReconnectRequestHandler handles it. The effect is if a request for the server comes in during this window, it will fail. If that request is part of a domain operation rollout (because during the window the HC regarded the server as 'live' and instructed the DC to send rollout ops to it), then the domain rollout will be affected. This happened in the testsuite failure I just saw. Most significant logging is as follows:
> {code}
> 2015-09-18 17:59:32,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" (Host Controller) started in 93ms - Started 48 of 51 services (15 services are lazy, passive or on-demand)
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-16) Initialized for 1849055188
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-14) WFLYHC0021: Server [Server:main-three] connected using connection [Channel ID 08aa200b (inbound) of Remoting connection 27e3d90d to /127.0.0.1:49272]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-15) WFLYHC0021: Server [Server:other-two] connected using connection [Channel ID 02bd2646 (inbound) of Remoting connection 64a8b7f2 to /127.0.0.1:49273]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) Initialized for 1849055188
> 2015-09-18 17:59:32,252 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) sending prepared response for 1849055188  --- interrupted: false
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 481103151
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) Initialized for 481103151
> 2015-09-18 17:59:32,255 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) sending pre-prepare failed response for 1933145457  --- interrupted: false
> 2015-09-18 17:59:32,256 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) sending pre-prepare failed response for 481103151  --- interrupted: false
> {code}
> The HC completes boot. Then servers main-three and other-two register. The HC sends a prepared response to a request. This is the host rollout request to the slave from the DC with the response being the ops to invoke on the servers. The HC reports sending a "pre-prepare failed response" to two requests. These are the requests the DC has asked it to proxy to the servers.
> The result of all this for the client is the following failure of a management op:
> {code}
> Failed operation:
> {
>     "operation" => "add",
>     "address" => [("extension" => "org.jboss.as.test.hc.extension")]
> }
> Response:
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"slave" => {"main-three" => "WFLYHC0153: Channel closed"}}},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => "WFLYHC0153: Channel closed"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {
>             "master" => {"main-one" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => [("HC" => "1.1.1")],
>                 "rolled-back" => true
>             }}},
>             "slave" => {"main-three" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => undefined,
>                 "failure-description" => "WFLYHC0153: Channel closed",
>                 "rolled-back" => true
>             }}}
>         }},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYHC0153: Channel closed",
>             "rolled-back" => true
>         }}}}}
>     }
> }
> {code}
> The "WFLYHC0153: Channel closed" failure is what is produced when an attempt is made to invoke on a disconnected proxy controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.2097.1442883000973@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-988:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.2100.1442883001028@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-979:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
>                 Key: WFCORE-979
>                 URL: https://issues.jboss.org/browse/WFCORE-979
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR4
>
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
>  testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >  
> >      <domain-controller>
> >          <!-- Remote domain controller configuration with a host and port -->
> > -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-932) stop-embedded-server stops
 the embedded host controller and vice versa
In-Reply-To: <JIRA.12583124.1440765129000@Atlassian.JIRA>
References: <JIRA.12583124.1440765129000@Atlassian.JIRA>
	<JIRA.12583124.1440765129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583124.1440765129000.2108.1442883001339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-932:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> stop-embedded-server stops the embedded host controller and vice versa
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-932
>                 URL: https://issues.jboss.org/browse/WFCORE-932
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>             Fix For: 2.0.0.CR4
>
>
> We have four new commands for controlling the lifecycle of embedded instances:
> * *embed-server* - launch embedded standalone
> * *stop-embedded-server* - stop embedded standalone
> * *embed-host-controller* - launch embedded host
> * *stop-embedded-host-controller* - stop embedded host
> \\
> I am able stop embedded standalone by *stop-embedded-host-controller* and embedded host controller by *stop-embedded-server*.
> {noformat}
> [disconnected /] embed-server 
> [standalone at embedded /] stop-embedded-host-controller 
> [disconnected /] embed-host-controller 
> 14:22:18,781 INFO  [org.jboss.modules] (AeshProcess: 15) JBoss Modules version 1.4.3.Final
> [domain at embedded /] stop-embedded-server 
> [disconnected /]
> {noformat}
> \\
> A question comes to my mind, do we need two commands for stopping the embedded instance?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-931) Embedded host-controller
 throws NPE on regular shutdown
In-Reply-To: <JIRA.12583118.1440763207000@Atlassian.JIRA>
References: <JIRA.12583118.1440763207000@Atlassian.JIRA>
	<JIRA.12583118.1440763207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583118.1440763207000.2113.1442883001560@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-931:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> Embedded host-controller throws NPE on regular shutdown
> -------------------------------------------------------
>
>                 Key: WFCORE-931
>                 URL: https://issues.jboss.org/browse/WFCORE-931
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR4
>
>
> Invoking the /host=master:shutdown operation on embedded host-controller gives me NPE.
> *Standalone*
> {noformat}
> [standalone at embedded /] shutdown
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [standalone at embedded /] :shutdown
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0031: No operation named 'shutdown' exists at address []",
>     "rolled-back" => true
> }
> {noformat}
> \\
> *Domain*
> Using operation style :shutdown throws NPE. Tab completion for this operation works, which could be a little bit misleading in this case.
> {noformat}
> [domain at embedded /] shutdown --host=master
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> [domain at embedded /] /host=master:shutdown
> 13:34:57,512 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 3) WFLYCTL0013: Operation ("shutdown") failed - address: ([("host" => "master")]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:911)
> 	at org.jboss.as.host.controller.DomainModelControllerService.stopLocalHost(DomainModelControllerService.java:903)
> 	at org.jboss.as.host.controller.operations.HostShutdownHandler$1.execute(HostShutdownHandler.java:89)
> 	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:1296)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:212)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:661)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:651)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:85)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:728)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> [domain at embedded /] :read-resource
> Failed to execute operation.: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> [domain at embedded /] stop-embedded-host-controller 
> 13:35:19,252 ERROR [org.jboss.as.protocol] (AeshProcess: 5) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 626966ee: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1165)
> 	at org.jboss.as.cli.embedded.StopEmbeddedHostControllerHandler.doHandle(StopEmbeddedHostControllerHandler.java:56)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:751)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:774)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:389)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-937) --std-out=discard for
 embedded host controller doesn't work
In-Reply-To: <JIRA.12583210.1441006072000@Atlassian.JIRA>
References: <JIRA.12583210.1441006072000@Atlassian.JIRA>
	<JIRA.12583210.1441006072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583210.1441006072000.2104.1442883001105@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-937:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> --std-out=discard for embedded host controller doesn't work
> -----------------------------------------------------------
>
>                 Key: WFCORE-937
>                 URL: https://issues.jboss.org/browse/WFCORE-937
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR4
>
>
> Embedded host controller always prints the logs to the console no matter which --std-out= value I choose.
> {noformat}
> [disconnected /] embed-host-controller --std-out=discard
> 09:22:06,627 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.3.Final
> 09:22:06,733 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
> 09:22:06,758 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 09:22:07,769 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,799 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,824 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,843 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:08,067 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) (Host Controller) started in 1353ms - Started 25 of 27 services (8 services are lazy, passive or on-demand)
> [domain at embedded /] stop-embedded-host-controller 
> 09:22:15,926 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 5ms
> [disconnected /] exit 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.2116.1442883001698@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-909:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0.CR4
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 20:50:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 20:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.2118.1442883001766@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-628:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR4
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 21:51:00 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Mon, 21 Sep 2015 21:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.2133.1442886660276@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111070#comment-13111070 ] 

?? ? commented on DROOLS-880:
-----------------------------

Edison, I solved this issuse. The issue is my environment you said.
Thank you very much. I close this issue. 

> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 21 21:52:00 2015
From: issues at jboss.org (=?UTF-8?Q?=EC=9E=AC=EC=9A=B0_=EC=9D=B4_=28JIRA=29?=)
Date: Mon, 21 Sep 2015 21:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-880) Return a success response
 but the rule seems to be not running.
In-Reply-To: <JIRA.12581059.1439433926000@Atlassian.JIRA>
References: <JIRA.12581059.1439433926000@Atlassian.JIRA>
	<JIRA.12581059.1439433926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581059.1439433926000.2137.1442886720325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

?? ? closed DROOLS-880.
-----------------------
    Fix Version/s: 6.3.0.CR2
       Resolution: Done


> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
>                 Key: DROOLS-880
>                 URL: https://issues.jboss.org/browse/DROOLS-880
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR1
>         Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
>            Reporter: ?? ?
>            Assignee: Edson Tirelli
>             Fix For: 6.3.0.CR2
>
>         Attachments: 2015_08_20_11_27_43_987.mp4, method_not_allowed.png, Screenshot 2015-09-03 17.08.40.png, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 21 21:53:00 2015
From: issues at jboss.org (Theo Cleminson (JIRA))
Date: Mon, 21 Sep 2015 21:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4814) DirectoryNotEmptyException on
 undeploy of ear
In-Reply-To: <JIRA.12575791.1434898929000@Atlassian.JIRA>
References: <JIRA.12575791.1434898929000@Atlassian.JIRA>
	<JIRA.12575791.1434898929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575791.1434898929000.2142.1442886780265@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111071#comment-13111071 ] 

Theo Cleminson commented on WFLY-4814:
--------------------------------------

I'm seeing this issue in domain mode.
wildfly 9.0.1, RHEL7, oracle JDK1.8.0_60
attempting to remove content from a server group.

[wf-master204]$ [Host Controller] 11:38:38,819 ERROR [org.jboss.as.repository] (XNIO-1 task-10) WFLYDR0010: Couldn't delete content /app/jboss/domain/wf-master204/domain/data/content/c2: java.nio.file.DirectoryNotEmptyException: /app/jboss/domain/wf-master204/domain/data/content/c2
[Host Controller] 	at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
[Host Controller] 	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
[Host Controller] 	at java.nio.file.Files.deleteIfExists(Files.java:1165)
[Host Controller] 	at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
[Host Controller] 	at org.jboss.as.domain.controller.operations.deployment.DeploymentRemoveHandler$MasterDeploymentRemoveHandler.removeContent(DeploymentRemoveHandler.java:134)
[Host Controller] 	at org.jboss.as.domain.controller.operations.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:93)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1401)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1381)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1332)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1307)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1180)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:937)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:885)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
[Host Controller] 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
[Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
[Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
[Host Controller] 	at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
[Host Controller] 	at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
[Host Controller] 	at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
[Host Controller] 	at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
[Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)


> DirectoryNotEmptyException on undeploy of ear
> ---------------------------------------------
>
>                 Key: WFLY-4814
>                 URL: https://issues.jboss.org/browse/WFLY-4814
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Alpha4
>         Environment: Oracle Solaris SPARC 10, Oracle JDK 1.8.0_45.
>            Reporter: Frank Langelage
>            Assignee: Jason Greene
>
> When undeploying my ear by removing the ear file from the standalone/deployments folder I sometimes see this exception at the end:
> 21.06. 16:49:25,674 INFO  [org.jboss.as.server.deployment#stop] WFLYSRV0028: Stopped deployment maj2e-langfr-dev.ear (runtime-name: maj2e-langfr-dev.ear) in 3072ms
> 21.06. 16:49:26,034 ERROR [org.jboss.as.repository#removeContent] WFLYDR0010: Couldn't delete content /mbi/tools/jboss/10.0/standalone/data/content/30: java.nio.file.DirectoryNotEmptyException: /mbi/tools/jboss/10.0/standalone/data/content/30
> 	at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
> 	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> 	at java.nio.file.Files.deleteIfExists(Files.java:1165)
> 	at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
> 	at org.jboss.as.server.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:118)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1420)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1400)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1351)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1199)
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:956)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:904)
> 	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.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:747)
> 	at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:741)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:741)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 	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)
> 21.06. 16:49:26,174 INFO  [org.jboss.as.repository#removeContent] WFLYDR0002: Content removed from location /mbi/tools/jboss/10.0/standalone/data/content/30/4fee5b5fa782d2a7f04723ccab3e12351d600b/content
> 21.06. 16:49:26,176 INFO  [org.jboss.as.server#handleResult] WFLYSRV0009: Undeployed "maj2e-langfr-dev.ear" (runtime-name: "maj2e-langfr-dev.ear")
> The exception seems to be ignored. But the named folder and 
> a file /mbi/tools/jboss/10.0/standalone/data/content/30/7cb1f70d08fb375010369eea154c5db479eaba/content are still there.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 22:13:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Sep 2015 22:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-996) Race between commit and
 cancel messages if a domain rollout is cancelled
In-Reply-To: <JIRA.12585601.1442887953000@Atlassian.JIRA>
References: <JIRA.12585601.1442887953000@Atlassian.JIRA>
	<JIRA.12585601.1442887953990@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585601.1442887953000.2146.1442887980066@Atlassian.JIRA>

Brian Stansberry created WFCORE-996:
---------------------------------------

             Summary: Race between commit and cancel messages if a domain rollout is cancelled
                 Key: WFCORE-996
                 URL: https://issues.jboss.org/browse/WFCORE-996
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.CR3
            Reporter: Brian Stansberry


There are situations where the DomainRolloutStepHandler and DomainSlaveHandler may send a cancel message to the remote server or slave HC immediately after sending the tx commit/rollback message. This can happen in particular if a server is hanging after the commit messages are sent by DomainRolloutStepHandler and the user cancels while DomainRolloutStepHandler is waiting for final response. When execution proceeds to DomainSlaveHandler, it will send the commit messages to the slave HCs, and then, because the op is cancelled, immediately send cancel messages.

The problem is there's no guarantee of the order in which the messages will be processed by the recipient. And both the commit/rollback message and the cancel message use the ModelControllerProtocol.COMPLETE_TX_REQUEST message, with cancel using the ModelControllerProtocol.PARAM_ROLLBACK param. The effect of this is the remote process may process a COMPLETE_TX_REQUEST/PARAM_ROLLBACK representing the cancel *before* it processes a COMPLETE_TX_REQUEST/PARAM_COMMIT representing the tx commit. As a result tx will be rolled back on that process, even though the correct instruction is *commit*. The process will therefore be out of sync with the domain.

A simple way to reduce the possibility of this is to make DomainSlaveHandler a bit more patient when waiting for the final response from slave HCs when it knows it needs to cancel. Even if we can do more for current version slaves (see below), we should still do this in order to reduce the risk for legacy slaves.

Beyond that, we can *perhaps* change the messages to distinguish the cancel case from the rollback case. A whole new message type is one possibility, but then we'd need a new protocol version and would have to track the protocol version used by the slave and continue to send the old COMPLETE_TX_REQUEST message to legacy slaves. Simpler may be to introduce a new PARAM_CANCEL value for the message payload. Legacy slaves will still treat that as a rollback instruction, since by luck the TransactionalProtocolOperationHandler.CompleteTxOperationHandler treats any param value other than PARAM_COMMIT as meaning rollback. Current slaves though can use new handling for PARAM_CANCEL.

*Possible* handling for PARAM_CANCEL:

1) if ExecuteRequestContext.prepared == false --> cancel before prepare; go ahead and cancel
2) else if ERC.txCompleted == false --> set a new ERC.cancelled flag and wait for commit/rollback
3) else commit/rollback has already arrived; go ahead and cancel

The handling for commit/rollback would check ERC.cancelled after doing the commit'rollback and if true cancel the request.

This possible approach needs careful thought before being introduced though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 21 23:56:00 2015
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 21 Sep 2015 23:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5377) Security realm using ldaps
 hangs forever during SSL handshake, when ldap server is killed
In-Reply-To: <JIRA.12584934.1442312385000@Atlassian.JIRA>
References: <JIRA.12584934.1442312385000@Atlassian.JIRA>
	<JIRA.12584934.1442312385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584934.1442312385000.2161.1442894160146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-1072 to WFLY-5377:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5377  (was: JBEAP-1072)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Security
                           (was: Security)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR9)


> Security realm using ldaps hangs forever during SSL handshake, when ldap server is killed
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5377
>                 URL: https://issues.jboss.org/browse/WFLY-5377
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.0.0.CR1
>            Reporter: Martin Choma
>         Attachments: SecurityRealmLDAPSHandshakeHangs.pcap, StackTraceConnectTimeoutInLDAPSConnection.txt, StackTraceFromThreadDump.txt
>
>
> During failover testing we hit the problem of stuck thread. When ldap server is killed in particular time of ssl handshake EAP hangs and waits forever on response, which will never come. Causing thread to block forever. Same problem can be seen in LdapLoginModule using ldaps without specifying com.sun.jndi.ldap.connect.timeout value.
> Possible solution is to add option to declare com.sun.jndi.ldap.connect.timeout for security realm and provide some default non-empty value, e.g. 15 seconds.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 01:43:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Tue, 22 Sep 2015 01:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.2209.1442900580161@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111083#comment-13111083 ] 

Petr Kremensky commented on WFCORE-993:
---------------------------------------

This is obviously not related to embed-host-controller only. Reloading embed-server with admin-only=true is broken as well (notice that I've waited ~5s before every reload operation)
{noformat}
[disconnected /] embed-server --std-out=echo 
07:37:59,172 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
07:37:59,215 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
07:37:59,269 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:37:59,982 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:00,166 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 988ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true 
07:38:05,390 INFO  [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 24ms
07:38:05,394 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:05,461 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:05,529 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 131ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true
07:38:09,311 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 3ms
07:38:09,313 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:09,358 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:09,361 ERROR [org.jboss.as.controller] (AeshProcess: 3) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:38:09,417 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 103ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] embed-server --std-out=echo
The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
{noformat}

> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 01:44:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Tue, 22 Sep 2015 01:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.2212.1442900640142@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111083#comment-13111083 ] 

Petr Kremensky edited comment on WFCORE-993 at 9/22/15 1:43 AM:
----------------------------------------------------------------

This is obviously not related to embed-host-controller only. Reloading embed-server with admin-only=true is broken as well (notice that I've waited ~5s before every reload operation)
{noformat}
[disconnected /] embed-server --std-out=echo 
07:37:59,172 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
07:37:59,215 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
07:37:59,269 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:37:59,982 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:00,166 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 988ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true 
07:38:05,390 INFO  [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 24ms
07:38:05,394 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:05,461 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:05,529 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 131ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true
07:38:09,311 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 3ms
07:38:09,313 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:09,358 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:09,361 ERROR [org.jboss.as.controller] (AeshProcess: 3) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:38:09,417 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 103ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] embed-server --std-out=echo
The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
{noformat}

Regression against previous version.


was (Author: pkremens):
This is obviously not related to embed-host-controller only. Reloading embed-server with admin-only=true is broken as well (notice that I've waited ~5s before every reload operation)
{noformat}
[disconnected /] embed-server --std-out=echo 
07:37:59,172 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
07:37:59,215 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
07:37:59,269 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:37:59,982 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:00,166 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 988ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true 
07:38:05,390 INFO  [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 24ms
07:38:05,394 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:05,461 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:05,529 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 131ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true
07:38:09,311 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 3ms
07:38:09,313 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:09,358 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:09,361 ERROR [org.jboss.as.controller] (AeshProcess: 3) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:38:09,417 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 103ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] embed-server --std-out=echo
The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
{noformat}

> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 01:52:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Tue, 22 Sep 2015 01:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.2219.1442901120167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111085#comment-13111085 ] 

Petr Kremensky commented on WFCORE-993:
---------------------------------------

Mix of reload operations in cli script could lead into a crash of CLI process.
{noformat}
$ cat test.cli 
embed-server --std-out=echo
reload --admin-only=false
reload --admin-only=true
...
{noformat}
{noformat}
$ ./jboss-cli.sh --file=test.cli
...
07:48:01,871 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:48:01,920 ERROR [org.jboss.as.controller] (main) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:48:01,921 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 6) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:48:01,933 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=remoting/configuration=endpoint' are not available:
    org.wildfly.io.worker.default; There are no known registration points which can provide this capability.
07:48:01,936 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/http-listener=default' are not available:
    org.wildfly.network.socket-binding.http; There are no known registration points which can provide this capability.
    org.wildfly.io.buffer-pool.default; There are no known registration points which can provide this capability.
    org.wildfly.io.worker.default; There are no known registration points which can provide this capability.
07:48:01,940 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
07:48:01,945 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 1ms
07:48:07,904 ERROR [org.jboss.as.protocol] (main) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 707194ba: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.getActiveModelControllerClient(EmbeddedStandAloneServerFactory.java:393)
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.access$100(EmbeddedStandAloneServerFactory.java:210)
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl$2.getDelegate(EmbeddedStandAloneServerFactory.java:245)
	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
	at org.jboss.as.cli.handlers.ReloadHandler.ensureServerRebootComplete(ReloadHandler.java:222)
	at org.jboss.as.cli.handlers.ReloadHandler.doHandleEmbedded(ReloadHandler.java:182)
	at org.jboss.as.cli.handlers.ReloadHandler.doHandle(ReloadHandler.java:142)
	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:763)
	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:786)
	at org.jboss.as.cli.impl.CliLauncher.processFile(CliLauncher.java:333)
	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:261)
	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
	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.modules.Module.run(Module.java:308)
	at org.jboss.modules.Main.main(Main.java:487)

Failed to establish connection in 6056ms
{noformat}

Running the same script (without the first line) against a standalone server started in a normal manner (non-embedded) works fine (no error logs).

> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 01:55:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Tue, 22 Sep 2015 01:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.2222.1442901300136@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111083#comment-13111083 ] 

Petr Kremensky edited comment on WFCORE-993 at 9/22/15 1:54 AM:
----------------------------------------------------------------

This is obviously not related to embed-host-controller only. Reloading embed-server with admin-only=true is broken as well (notice that I've waited ~5s before every reload command)
{noformat}
[disconnected /] embed-server --std-out=echo 
07:37:59,172 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
07:37:59,215 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
07:37:59,269 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:37:59,982 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:00,166 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 988ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true 
07:38:05,390 INFO  [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 24ms
07:38:05,394 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:05,461 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:05,529 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 131ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true
07:38:09,311 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 3ms
07:38:09,313 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:09,358 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:09,361 ERROR [org.jboss.as.controller] (AeshProcess: 3) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:38:09,417 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 103ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] embed-server --std-out=echo
The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
{noformat}

Regression against previous version.


was (Author: pkremens):
This is obviously not related to embed-host-controller only. Reloading embed-server with admin-only=true is broken as well (notice that I've waited ~5s before every reload operation)
{noformat}
[disconnected /] embed-server --std-out=echo 
07:37:59,172 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
07:37:59,215 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
07:37:59,269 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:37:59,982 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:00,166 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 988ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true 
07:38:05,390 INFO  [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 24ms
07:38:05,394 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:05,461 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:05,529 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 131ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] reload --admin-only=true
07:38:09,311 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 3ms
07:38:09,313 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:38:09,358 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:38:09,361 ERROR [org.jboss.as.controller] (AeshProcess: 3) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:38:09,417 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) started in 103ms - Started 35 of 48 services (19 services are lazy, passive or on-demand)

[standalone at embedded /] embed-server --std-out=echo
The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
{noformat}

Regression against previous version.

> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 01:56:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Tue, 22 Sep 2015 01:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.2225.1442901360124@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111085#comment-13111085 ] 

Petr Kremensky edited comment on WFCORE-993 at 9/22/15 1:55 AM:
----------------------------------------------------------------

Mix of reload commands in cli script could lead into a crash of CLI process.
{noformat}
$ cat test.cli 
embed-server --std-out=echo
reload --admin-only=false
reload --admin-only=true
...
{noformat}
{noformat}
$ ./jboss-cli.sh --file=test.cli
...
07:48:01,871 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:48:01,920 ERROR [org.jboss.as.controller] (main) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:48:01,921 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 6) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:48:01,933 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=remoting/configuration=endpoint' are not available:
    org.wildfly.io.worker.default; There are no known registration points which can provide this capability.
07:48:01,936 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/http-listener=default' are not available:
    org.wildfly.network.socket-binding.http; There are no known registration points which can provide this capability.
    org.wildfly.io.buffer-pool.default; There are no known registration points which can provide this capability.
    org.wildfly.io.worker.default; There are no known registration points which can provide this capability.
07:48:01,940 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
07:48:01,945 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 1ms
07:48:07,904 ERROR [org.jboss.as.protocol] (main) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 707194ba: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.getActiveModelControllerClient(EmbeddedStandAloneServerFactory.java:393)
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.access$100(EmbeddedStandAloneServerFactory.java:210)
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl$2.getDelegate(EmbeddedStandAloneServerFactory.java:245)
	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
	at org.jboss.as.cli.handlers.ReloadHandler.ensureServerRebootComplete(ReloadHandler.java:222)
	at org.jboss.as.cli.handlers.ReloadHandler.doHandleEmbedded(ReloadHandler.java:182)
	at org.jboss.as.cli.handlers.ReloadHandler.doHandle(ReloadHandler.java:142)
	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:763)
	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:786)
	at org.jboss.as.cli.impl.CliLauncher.processFile(CliLauncher.java:333)
	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:261)
	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
	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.modules.Module.run(Module.java:308)
	at org.jboss.modules.Main.main(Main.java:487)

Failed to establish connection in 6056ms
{noformat}

Running the same script (without the first line) against a standalone server started in a normal manner (non-embedded) works fine (no error logs).


was (Author: pkremens):
Mix of reload operations in cli script could lead into a crash of CLI process.
{noformat}
$ cat test.cli 
embed-server --std-out=echo
reload --admin-only=false
reload --admin-only=true
...
{noformat}
{noformat}
$ ./jboss-cli.sh --file=test.cli
...
07:48:01,871 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) starting
07:48:01,920 ERROR [org.jboss.as.controller] (main) WFLYCTL0369: Required capabilities are not available:
    org.wildfly.network.socket-binding.management-http; Possible registration points for this capability: 
		/core-service=management/management-interface=http-interface
07:48:01,921 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 6) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
07:48:01,933 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=remoting/configuration=endpoint' are not available:
    org.wildfly.io.worker.default; There are no known registration points which can provide this capability.
07:48:01,936 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/http-listener=default' are not available:
    org.wildfly.network.socket-binding.http; There are no known registration points which can provide this capability.
    org.wildfly.io.buffer-pool.default; There are no known registration points which can provide this capability.
    org.wildfly.io.worker.default; There are no known registration points which can provide this capability.
07:48:01,940 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
07:48:01,945 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 10.0.0.CR1 (WildFly Core 2.0.0.CR1) stopped in 1ms
07:48:07,904 ERROR [org.jboss.as.protocol] (main) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 707194ba: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.getActiveModelControllerClient(EmbeddedStandAloneServerFactory.java:393)
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.access$100(EmbeddedStandAloneServerFactory.java:210)
	at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl$2.getDelegate(EmbeddedStandAloneServerFactory.java:245)
	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
	at org.jboss.as.cli.handlers.ReloadHandler.ensureServerRebootComplete(ReloadHandler.java:222)
	at org.jboss.as.cli.handlers.ReloadHandler.doHandleEmbedded(ReloadHandler.java:182)
	at org.jboss.as.cli.handlers.ReloadHandler.doHandle(ReloadHandler.java:142)
	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:763)
	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:786)
	at org.jboss.as.cli.impl.CliLauncher.processFile(CliLauncher.java:333)
	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:261)
	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
	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.modules.Module.run(Module.java:308)
	at org.jboss.modules.Main.main(Main.java:487)

Failed to establish connection in 6056ms
{noformat}

Running the same script (without the first line) against a standalone server started in a normal manner (non-embedded) works fine (no error logs).

> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 02:30:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 22 Sep 2015 02:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-930) Missing help texts for
 embedded host controller
In-Reply-To: <JIRA.12583108.1440761087000@Atlassian.JIRA>
References: <JIRA.12583108.1440761087000@Atlassian.JIRA>
	<JIRA.12583108.1440761087000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583108.1440761087000.2257.1442903400356@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-930:
-----------------------------
    Fix Version/s: 2.0.0.CR5


> Missing help texts for embedded host controller
> -----------------------------------------------
>
>                 Key: WFCORE-930
>                 URL: https://issues.jboss.org/browse/WFCORE-930
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR4
>
>
> Help files for embedded host controller are missing.
> {noformat}
> [disconnected /] embed-host-controller --help
> Failed to locate command description help/embed-host-controller.txt
> [domain at embedded /] stop-embedded-host-controller --help
> Failed to locate command description help/stop-embedded-host-controller.txt
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 02:30:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 22 Sep 2015 02:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-930) Missing help texts for
 embedded host controller
In-Reply-To: <JIRA.12583108.1440761087000@Atlassian.JIRA>
References: <JIRA.12583108.1440761087000@Atlassian.JIRA>
	<JIRA.12583108.1440761087000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583108.1440761087000.2260.1442903400423@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-930:
-----------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR5)


> Missing help texts for embedded host controller
> -----------------------------------------------
>
>                 Key: WFCORE-930
>                 URL: https://issues.jboss.org/browse/WFCORE-930
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR4
>
>
> Help files for embedded host controller are missing.
> {noformat}
> [disconnected /] embed-host-controller --help
> Failed to locate command description help/embed-host-controller.txt
> [domain at embedded /] stop-embedded-host-controller --help
> Failed to locate command description help/stop-embedded-host-controller.txt
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:05:00 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Tue, 22 Sep 2015 03:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.2297.1442905500222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
    Description: 
Description of problem:
It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.

ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java

I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.

Additional desired functionality
"the desired functionality is to, when a new request arrives
and there is an idle thread, use that thread instead of creating a new 
thread [up until max-threads]."

  was:
Description of problem:
It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.

ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java

I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.



> Allow configure max-threads and core-threads independently
> ----------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new 
> thread [up until max-threads]."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:06:00 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Tue, 22 Sep 2015 03:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.2301.1442905560138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
    Description: 
Description of problem:
It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.

ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java

I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.

Additional desired functionality according to PRODMGT-1401:
"the desired functionality is to, when a new request arrives
and there is an idle thread, use that thread instead of creating a new 
thread [up until max-threads]."

  was:
Description of problem:
It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.

ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java

I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.

Additional desired functionality
"the desired functionality is to, when a new request arrives
and there is an idle thread, use that thread instead of creating a new 
thread [up until max-threads]."



> Allow configure max-threads and core-threads independently
> ----------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new 
> thread [up until max-threads]."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:32:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 03:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-913) Memory leak when deleting a
 tuple from an unlinked segment
In-Reply-To: <JIRA.12584856.1442245949000@Atlassian.JIRA>
References: <JIRA.12584856.1442245949000@Atlassian.JIRA>
	<JIRA.12584856.1442245949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584856.1442245949000.2347.1442907120104@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111104#comment-13111104 ] 

RH Bugzilla Integration commented on DROOLS-913:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1263495|https://bugzilla.redhat.com/show_bug.cgi?id=1263495] from NEW to MODIFIED

> Memory leak when deleting a tuple from an unlinked segment
> ----------------------------------------------------------
>
>                 Key: DROOLS-913
>                 URL: https://issues.jboss.org/browse/DROOLS-913
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> When deleting an object from a session all references to the object itself and the fact handle holding it should disappear. Unfortunately, as demonstrated by the test case below, in some case the deleted fact can remain as a deleted left tuple in the memory of an unlinked segment.
> {code}
>     @Test
>     public void testBetaMemoryLeakOnFactDelete() {
>         String drl =
>                 "rule R1 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "    $c : Integer(this == 2)\n" +
>                 "then \n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "then \n" +
>                 "end\n";
>         KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
>                                              .build()
>                                              .newKieSession();
>         FactHandle fh1 = ksession.insert(1);
>         FactHandle fh2 = ksession.insert("test");
>         ksession.fireAllRules();
>         ksession.delete(fh1);
>         ksession.delete(fh2);
>         ksession.fireAllRules();
>         NodeMemories nodeMemories = ((InternalWorkingMemory) ksession).getNodeMemories();
>         for (int i = 0; i < nodeMemories.length(); i++) {
>             Memory memory = nodeMemories.peekNodeMemory( i );
>             if ( memory != null && memory.getSegmentMemory() != null ) {
>                 SegmentMemory segmentMemory = memory.getSegmentMemory();
>                 System.out.println( memory );
>                 LeftTuple deleteFirst = memory.getSegmentMemory().getStagedLeftTuples().getDeleteFirst();
>                 System.out.println( deleteFirst );
>                 assertNull( deleteFirst );
>             }
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:43:01 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Tue, 22 Sep 2015 03:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently. Allow idle thread reusage.
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.2374.1442907781147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
    Summary: Allow configure max-threads and core-threads independently. Allow idle thread reusage.  (was: Allow configure max-threads and core-threads independently)


> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new 
> thread [up until max-threads]."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:49:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 03:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-796) Native maven pom parser
 doesn't work under OSGi
In-Reply-To: <JIRA.12573129.1432818035000@Atlassian.JIRA>
References: <JIRA.12573129.1432818035000@Atlassian.JIRA>
	<JIRA.12573129.1432818035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573129.1432818035000.2383.1442908140273@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-796:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1242741
        Bugzilla Update: Perform


> Native maven pom parser doesn't work under OSGi
> -----------------------------------------------
>
>                 Key: DROOLS-796
>                 URL: https://issues.jboss.org/browse/DROOLS-796
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>         Attachments: switchyard-example-rules-kie.zip
>
>
> The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases.
> In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo:
> https://gist.github.com/dvirgiln/e5c69afc7434367e04c1
> This is executed on EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:53:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 22 Sep 2015 03:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5376) poor CSS formatting in
 Wildfly Web Admin Console under "Configuration" tab
In-Reply-To: <JIRA.12585575.1442859212000@Atlassian.JIRA>
References: <JIRA.12585575.1442859212000@Atlassian.JIRA>
	<JIRA.12585575.1442859212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585575.1442859212000.2390.1442908380172@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111110#comment-13111110 ] 

Heiko Braun commented on WFLY-5376:
-----------------------------------

We use very long TTL's (30 days) for the web content. So sometimes, when  a new WF version is accessed, it incorrectly relies on the CSS files in your cache.  

> poor CSS formatting in Wildfly Web Admin Console under "Configuration" tab
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5376
>                 URL: https://issues.jboss.org/browse/WFLY-5376
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.0.0.CR1
>            Reporter: The Alchemist
>            Assignee: Heiko Braun
>            Priority: Minor
>         Attachments: screenshot-1.png
>
>
> h2. Screenshot
> !screenshot-1.png!
> h2. Specs
> * Mac OS X 10.10.5
> * MacBook Pro (Retina, 15-inch, Late 2013)
> * Chrome  45.0.2454.93 (64-bit)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:59:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 03:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-796) Native maven pom parser
 doesn't work under OSGi
In-Reply-To: <JIRA.12573129.1432818035000@Atlassian.JIRA>
References: <JIRA.12573129.1432818035000@Atlassian.JIRA>
	<JIRA.12573129.1432818035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573129.1432818035000.2408.1442908740348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-796:
-------------------------------------------
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=1242741)
        Bugzilla Update:   (was: Perform)


> Native maven pom parser doesn't work under OSGi
> -----------------------------------------------
>
>                 Key: DROOLS-796
>                 URL: https://issues.jboss.org/browse/DROOLS-796
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>         Attachments: switchyard-example-rules-kie.zip
>
>
> The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases.
> In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo:
> https://gist.github.com/dvirgiln/e5c69afc7434367e04c1
> This is executed on EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 03:59:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 03:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-796) Native maven pom parser
 doesn't work under OSGi
In-Reply-To: <JIRA.12573129.1432818035000@Atlassian.JIRA>
References: <JIRA.12573129.1432818035000@Atlassian.JIRA>
	<JIRA.12573129.1432818035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573129.1432818035000.2412.1442908741061@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-796:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1200301
        Bugzilla Update: Perform


> Native maven pom parser doesn't work under OSGi
> -----------------------------------------------
>
>                 Key: DROOLS-796
>                 URL: https://issues.jboss.org/browse/DROOLS-796
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: David virgil naranjo
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Beta2
>
>         Attachments: switchyard-example-rules-kie.zip
>
>
> The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases.
> In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo:
> https://gist.github.com/dvirgiln/e5c69afc7434367e04c1
> This is executed on EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:01:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 04:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-803) Drools invokes superclass
 static method when running on IBM JDK
In-Reply-To: <JIRA.12573519.1433239014000@Atlassian.JIRA>
References: <JIRA.12573519.1433239014000@Atlassian.JIRA>
	<JIRA.12573519.1433239014000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573519.1433239014000.2415.1442908861310@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111113#comment-13111113 ] 

RH Bugzilla Integration commented on DROOLS-803:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1227274|https://bugzilla.redhat.com/show_bug.cgi?id=1227274] from ASSIGNED to MODIFIED

> Drools invokes superclass static method when running on IBM JDK
> ---------------------------------------------------------------
>
>                 Key: DROOLS-803
>                 URL: https://issues.jboss.org/browse/DROOLS-803
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 6.3.0.Beta2
>
>
> When a static method with the same signature is declared by a class and its superclass Drools mistakenly invokes the one of the superclass even when it shouldn't. This happens only on IBM JDK.
> This issue is related to https://issues.jboss.org/browse/DROOLS-410



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 22 04:07:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 04:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-899) Kie-ci sends MavenRequest
 without considering the repositories defined in user settings file
In-Reply-To: <JIRA.12583317.1441037294000@Atlassian.JIRA>
References: <JIRA.12583317.1441037294000@Atlassian.JIRA>
	<JIRA.12583317.1441037294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583317.1441037294000.2432.1442909220626@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111116#comment-13111116 ] 

RH Bugzilla Integration commented on DROOLS-899:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1259589|https://bugzilla.redhat.com/show_bug.cgi?id=1259589] from MODIFIED to ON_QA

> Kie-ci sends MavenRequest without considering the repositories defined in user settings file
> --------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-899
>                 URL: https://issues.jboss.org/browse/DROOLS-899
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:07:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 04:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-886) ClassCastException when
 kcontainer.updateToVersion() with sliding window rule running (with fix for
 DROOLS-881 and DROOLS-883)
In-Reply-To: <JIRA.12581669.1439893031000@Atlassian.JIRA>
References: <JIRA.12581669.1439893031000@Atlassian.JIRA>
	<JIRA.12581669.1439893031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581669.1439893031000.2440.1442909221056@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111118#comment-13111118 ] 

RH Bugzilla Integration commented on DROOLS-886:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1254528|https://bugzilla.redhat.com/show_bug.cgi?id=1254528] from MODIFIED to ON_QA

> ClassCastException when kcontainer.updateToVersion() with sliding window rule running (with fix for DROOLS-881 and DROOLS-883)
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-886
>                 URL: https://issues.jboss.org/browse/DROOLS-886
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.CR1
>         Environment: drools.version:  6.4.0-SNAPSHOT
>            Reporter: hisao furuichi
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>         Attachments: reproducer2.zip
>
>
> When you call kcontainer.updateToVersion() while running sliding window rules, you will the following Exception.
> I tested it with master(6.4.0-SNAPSHOT), and I guess it includes the fix for  DROOLS-881 and DROOLS-883. However the issue still occurs.
> {panel}
> Exception in thread "pool-23-thread-1" java.lang.ClassCastException: org.drools.core.reteoo.WindowNode$WindowMemory cannot be cast to org.drools.core.reteoo.PathMemory
> 	at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:85)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:190)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:136)
> 	at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:102)
> 	at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1521)
> 	at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1501)
> 	at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:966)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:256)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:120)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:104)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:369)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:207)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:128)
> 	at com.sample.CallKjarTest$1.run(CallKjarTest.java:45)
> 	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)
> {panel}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:07:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 04:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-883) Deadlock with
 kcontainer.updateToVersion() under load
In-Reply-To: <JIRA.12581519.1439787370000@Atlassian.JIRA>
References: <JIRA.12581519.1439787370000@Atlassian.JIRA>
	<JIRA.12581519.1439787370000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581519.1439787370000.2445.1442909221310@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111119#comment-13111119 ] 

RH Bugzilla Integration commented on DROOLS-883:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1254404|https://bugzilla.redhat.com/show_bug.cgi?id=1254404] from MODIFIED to ON_QA

> Deadlock with kcontainer.updateToVersion() under load
> -----------------------------------------------------
>
>                 Key: DROOLS-883
>                 URL: https://issues.jboss.org/browse/DROOLS-883
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>         Environment: Tested with master after DROOLS-881 is fixed
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>         Attachments: deadlock.txt, deadlockWithUpdateToVersion.zip
>
>
> Calling kcontainer.updateToVersion() under load causes a deadlock. See attached reproducer and thread dump.
> {noformat}
> Found one Java-level deadlock:
> =============================
> "pool-8-thread-11":
>   waiting for ownable synchronizer 0x00000007bd812568, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
>   which is held by "pool-8-thread-4"
> "pool-8-thread-4":
>   waiting for ownable synchronizer 0x000000070a08e9f8, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
>   which is held by "pool-8-thread-1"
> "pool-8-thread-1":
>   waiting for ownable synchronizer 0x00000007bd812568, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
>   which is held by "pool-8-thread-4"
> Java stack information for the threads listed above:
> ===================================================
> "pool-8-thread-11":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007bd812568> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:190)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1477)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1432)
> 	at com.sample.CallKjarTest$2.run(CallKjarTest.java:66)
> 	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)
> "pool-8-thread-4":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x000000070a08e9f8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
> 	at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:731)
> 	at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:700)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:191)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1477)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1432)
> 	at com.sample.CallKjarTest$2.run(CallKjarTest.java:66)
> 	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)
> "pool-8-thread-1":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007bd812568> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> 	at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:481)
> 	at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:468)
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl$WorkingMemoryReteExpireAction.execute(StatefulKnowledgeSessionImpl.java:1779)
>         at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
>         at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2007)
>         at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:153)
>         at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:161)
>         at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:155)
>         - locked <0x00000007bd7cbfd8> (a org.drools.core.reteoo.ReteooBuilder)
>         at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1608)
>         at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1599)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.preProcessRules(KnowledgeBuilderImpl.java:1141)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1084)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:967)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:256)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:120)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:104)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:369)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:207)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:128)
>         at com.sample.CallKjarTest$1.run(CallKjarTest.java:45)
>         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)
> Found 1 deadlock.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:07:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 04:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-858) NoSuchMethodError on JIT
 Compilation of non-primitive comparison
In-Reply-To: <JIRA.12579278.1437730819000@Atlassian.JIRA>
References: <JIRA.12579278.1437730819000@Atlassian.JIRA>
	<JIRA.12579278.1437730819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579278.1437730819000.2454.1442909221670@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111121#comment-13111121 ] 

RH Bugzilla Integration commented on DROOLS-858:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1251826|https://bugzilla.redhat.com/show_bug.cgi?id=1251826] from MODIFIED to ON_QA

> NoSuchMethodError on JIT Compilation of non-primitive comparison
> ----------------------------------------------------------------
>
>                 Key: DROOLS-858
>                 URL: https://issues.jboss.org/browse/DROOLS-858
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Beta2
>            Reporter: Sascha Dirbach
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR1
>
>         Attachments: ConditionEvaluator898a83b4ea6745eaa1b63420a059d717.class
>
>
> A LHS like this:
> {code}
> $map : Map()
> $simpleTestObject : NonStringConstructorClass (something=="simpleTestObject")
> Entry (
>   getKey() == $simpleTestObject
> ) from $map.entrySet()
> {code}
> fails at runtime with a NoSuchMethodError, when incompatible objects are compared (Map with object vs. custom Object) and the execution is jitted.
> The generated evaluation method looks like this:
> {code}
>   public boolean evaluate(InternalFactHandle paramInternalFactHandle, InternalWorkingMemory paramInternalWorkingMemory, LeftTuple paramLeftTuple)
>   {
>     LeftTuple localLeftTuple = paramLeftTuple;
>     NonStringConstructorClass localNonStringConstructorClass2 = (NonStringConstructorClass)this.declarations[0].getValue(paramInternalWorkingMemory, localLeftTuple.getHandle().getObject());
>     Object localObject = ((Map.Entry)paramInternalFactHandle.getObject()).getKey();
>     NonStringConstructorClass localNonStringConstructorClass1 = localNonStringConstructorClass2;
>     if (localObject != null)
>     {
>       if ((localObject instanceof NonStringConstructorClass)) {
>         localObject = (NonStringConstructorClass)localObject;
>       } else {
>         localObject = new NonStringConstructorClass(localObject.toString());
>       }
>     }
>     else
>     {
>       tmpTernaryOp = (localNonStringConstructorClass1 != null ? 0 : true;
>       break label123;
>     }
>     label123:
>     return localNonStringConstructorClass1 == null ? false : ((NonStringConstructorClass)localObject).equals(localNonStringConstructorClass1);
>   }
> }
> {code}
> It seem that, a fallback for primitive types was included, by calling the constructor of an object with the object's toString() output:
> {code}
> localObject = new NonStringConstructorClass(localObject.toString());
> {code}
> At runtime this fails, if no such constructor exists.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:07:02 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 04:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-881) ClassCastException when
 kcontainer.updateToVersion() with sliding window rule running
In-Reply-To: <JIRA.12581064.1439449240000@Atlassian.JIRA>
References: <JIRA.12581064.1439449240000@Atlassian.JIRA>
	<JIRA.12581064.1439449240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581064.1439449240000.2463.1442909222087@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111123#comment-13111123 ] 

RH Bugzilla Integration commented on DROOLS-881:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1253162|https://bugzilla.redhat.com/show_bug.cgi?id=1253162] from MODIFIED to ON_QA

> ClassCastException when kcontainer.updateToVersion() with sliding window rule running
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-881
>                 URL: https://issues.jboss.org/browse/DROOLS-881
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.CR1
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR2
>
>         Attachments: 01490327_standalone_reproducer.zip
>
>
> When you call kcontainer.updateToVersion() while running sliding window rules, you will the following Exception.
> {noformat}
> Exception in thread "pool-23-thread-2" java.lang.ClassCastException: org.drools.core.reteoo.PathMemory cannot be cast to org.drools.core.reteoo.WindowNode$WindowMemory
> 	at org.drools.core.reteoo.WindowNode.retractRightTuple(WindowNode.java:189)
> 	at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:325)
> 	at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl$WorkingMemoryReteExpireAction.execute(StatefulKnowledgeSessionImpl.java:1770)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2007)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1272)
> 	at com.sample.CallKjarTest$2.run(CallKjarTest.java:67)
> 	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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:18:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 04:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.2485.1442909880271@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111125#comment-13111125 ] 

ehsavoie Hugonnet commented on WFCORE-756:
------------------------------------------

Trying to reproduce this morning I got the following error :( :
10:15:12,144 ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Endpoint is not open
        at org.jboss.remoting3.EndpointImpl.executorUntick(EndpointImpl.java:200)
        at org.jboss.remoting3.EndpointImpl$TrackingExecutor.execute(EndpointImpl.java:700)
        at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
        at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at org.xnio.channels.TranslatingSuspendableChannel.close(TranslatingSuspendableChannel.java:906)
        at org.xnio.IoUtils.safeClose(IoUtils.java:134)
        at org.xnio.channels.TranslatingSuspendableChannel$3.handleEvent(TranslatingSuspendableChannel.java:133)
        at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
        at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at org.xnio.StreamConnection.invokeCloseListener(StreamConnection.java:80)
        at org.xnio.Connection.writeClosed(Connection.java:117)
        at org.xnio.nio.AbstractNioStreamConnection.writeClosed(AbstractNioStreamConnection.java:47)
        at org.xnio.nio.NioSocketConduit.terminateWrites(NioSocketConduit.java:181)
        at org.xnio.nio.NioSocketConduit.truncateWrites(NioSocketConduit.java:191)
        at org.xnio.conduits.ConduitStreamSinkChannel.close(ConduitStreamSinkChannel.java:186)
        at org.xnio.IoUtils.safeClose(IoUtils.java:134)
        at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.forceTermination(WriteReadyHandler.java:57)
        at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:107)
        at org.xnio.nio.WorkerThread.run(WorkerThread.java:490)

> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:28:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 22 Sep 2015 04:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5378) Upgrade HAL to 2.8.11.Final
In-Reply-To: <JIRA.12585616.1442910441000@Atlassian.JIRA>
References: <JIRA.12585616.1442910441000@Atlassian.JIRA>
	<JIRA.12585616.1442910441260@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585616.1442910441000.2525.1442910480215@Atlassian.JIRA>

Harald Pehl created WFLY-5378:
---------------------------------

             Summary: Upgrade HAL to 2.8.11.Final
                 Key: WFLY-5378
                 URL: https://issues.jboss.org/browse/WFLY-5378
             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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:28:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 22 Sep 2015 04:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5378) Upgrade HAL to 2.8.11.Final
In-Reply-To: <JIRA.12585616.1442910441000@Atlassian.JIRA>
References: <JIRA.12585616.1442910441000@Atlassian.JIRA>
	<JIRA.12585616.1442910441000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585616.1442910441000.2530.1442910480529@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-5378:
------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/8126)


> Upgrade HAL to 2.8.11.Final
> ---------------------------
>
>                 Key: WFLY-5378
>                 URL: https://issues.jboss.org/browse/WFLY-5378
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.CR2
>
>
> New homepage and bugfixes



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:28:00 2015
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 22 Sep 2015 04:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5378) Upgrade HAL to 2.8.11.Final
In-Reply-To: <JIRA.12585616.1442910441000@Atlassian.JIRA>
References: <JIRA.12585616.1442910441000@Atlassian.JIRA>
	<JIRA.12585616.1442910441000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585616.1442910441000.2532.1442910480595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-5378:
------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.CR1)


> Upgrade HAL to 2.8.11.Final
> ---------------------------
>
>                 Key: WFLY-5378
>                 URL: https://issues.jboss.org/browse/WFLY-5378
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.CR2
>
>
> New homepage and bugfixes



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:37:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 22 Sep 2015 04:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.2547.1442911020260@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111136#comment-13111136 ] 

Jeff Mesnil commented on WFLY-5374:
-----------------------------------

I can not reproduce it locally but I suspect the error comes from the native libs from our artemis 1.1.0-wildfly-6 branch.
Could you confirm it starts fine when the journal-type is set to NIO instead?


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:49:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 04:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.2567.1442911740472@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reopened WFCORE-756:
--------------------------------------


I'm reproducing the problem with a different stack trace due to [~dmlloyd] upgrade of remoting.


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 04:50:01 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 04:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.2574.1442911801496@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-756:
-------------------------------------
    Attachment: server.log


Attaching log file, org.xnio.nio is at trace level

> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>         Attachments: server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:13:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 05:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.2821.1442913180482@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-756:
-------------------------------------
    Attachment: server.log


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>         Attachments: server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:13:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 05:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.2832.1442913180917@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-756:
-------------------------------------
    Attachment:     (was: server.log)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>         Attachments: server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:14:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 22 Sep 2015 05:14:00 -0400 (EDT)
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.2835.1442913240166@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-4964.
-------------------------------
    Fix Version/s: 10.0.0.CR1
       Resolution: Done


Upstream issue has been fixed in Artemis 1.1.0-wildfly-6

> 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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 22 05:26:02 2015
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 22 Sep 2015 05:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5379) Upgrade Narayana to
	5.2.3.Final
In-Reply-To: <JIRA.12585624.1442913947000@Atlassian.JIRA>
References: <JIRA.12585624.1442913947000@Atlassian.JIRA>
	<JIRA.12585624.1442913947774@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585624.1442913947000.2933.1442913962826@Atlassian.JIRA>

Michael Musgrove created WFLY-5379:
--------------------------------------

             Summary: Upgrade Narayana to 5.2.3.Final
                 Key: WFLY-5379
                 URL: https://issues.jboss.org/browse/WFLY-5379
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Transactions
    Affects Versions: 10.0.0.CR1
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 10.0.0.CR2


Includes miscellaneous bug fixes 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:30:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 22 Sep 2015 05:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-292) Sasl server filtering with
	credential names
In-Reply-To: <JIRA.12585626.1442914163000@Atlassian.JIRA>
References: <JIRA.12585626.1442914163000@Atlassian.JIRA>
	<JIRA.12585626.1442914163862@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585626.1442914163000.2954.1442914200186@Atlassian.JIRA>

Jan Kalina created ELY-292:
------------------------------

             Summary: Sasl server filtering with credential names
                 Key: ELY-292
                 URL: https://issues.jboss.org/browse/ELY-292
             Project: WildFly Elytron
          Issue Type: Task
            Reporter: Jan Kalina


Meaning of `FilterMechanismSaslServer` should change, as the way of getting credential was changed. In past it was base on data type of credential, now it is base on credential names.

See* `FilterMechanismSaslServer` constructor (filtering part commented out for now)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:46:01 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Tue, 22 Sep 2015 05:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.2999.1442915161244@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111167#comment-13111167 ] 

Miroslav Novak commented on WFLY-5374:
--------------------------------------

You're right. Server starts without problem with journal-type to NIO. Start with ASYNCIO (which is default) always fails. 

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:46:01 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Tue, 22 Sep 2015 05:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.3006.1442915161428@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111167#comment-13111167 ] 

Miroslav Novak edited comment on WFLY-5374 at 9/22/15 5:45 AM:
---------------------------------------------------------------

You're right. Server starts without problem with journal-type set to NIO. Start with ASYNCIO (which is default) always fails. 


was (Author: mnovak):
You're right. Server starts without problem with journal-type to NIO. Start with ASYNCIO (which is default) always fails. 

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:58:00 2015
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 22 Sep 2015 05:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-997) Security realm using ldaps
 hangs forever during SSL handshake, when ldap server is killed
In-Reply-To: <JIRA.12585602.1442894011000@Atlassian.JIRA>
References: <JIRA.12585602.1442894011000@Atlassian.JIRA>
	<JIRA.12585602.1442894011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585602.1442894011000.3026.1442915880115@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-1125 to WFCORE-997:
--------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-997  (was: JBEAP-1125)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Security
                           (was: Security)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.CR3
                           (was: 7.0.0.DR9)


> Security realm using ldaps hangs forever during SSL handshake, when ldap server is killed
> -----------------------------------------------------------------------------------------
>
>                 Key: WFCORE-997
>                 URL: https://issues.jboss.org/browse/WFCORE-997
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 2.0.0.CR3
>            Reporter: Martin Choma
>         Attachments: SecurityRealmLDAPSHandshakeHangs.pcap, StackTraceConnectTimeoutInLDAPSConnection.txt, StackTraceFromThreadDump.txt
>
>
> During failover testing we hit the problem of stuck thread. When ldap server is killed in particular time of ssl handshake EAP hangs and waits forever on response, which will never come. Causing thread to block forever. Same problem can be seen in LdapLoginModule using ldaps without specifying com.sun.jndi.ldap.connect.timeout value.
> Possible solution is to add option to declare com.sun.jndi.ldap.connect.timeout for security realm and provide some default non-empty value, e.g. 15 seconds.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:59:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 05:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.3031.1442915940230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-3990:
------------------------------
    Component/s: EE


> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE, EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 05:59:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 05:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.3036.1442915940354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-3990:
---------------------------------

    Assignee: Tomaz Cerar


> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE, EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>            Assignee: Tomaz Cerar
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 06:12:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 22 Sep 2015 06:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5380) [Migration operation] Do not
 create legacy connection factory for connection factories with in-vm
 connector
In-Reply-To: <JIRA.12585634.1442916668000@Atlassian.JIRA>
References: <JIRA.12585634.1442916668000@Atlassian.JIRA>
	<JIRA.12585634.1442916668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585634.1442916668000.3048.1442916720199@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-1127 to WFLY-5380:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5380  (was: JBEAP-1127)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: JMS
                           (was: JMS)
                           (was: Migration)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR9)


> [Migration operation] Do not create legacy connection factory for connection factories with in-vm connector
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5380
>                 URL: https://issues.jboss.org/browse/WFLY-5380
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>              Labels: Migration
>
> If connection factory contains in-vm connector and legacy connection factory is created by migration operation then server won't start and fails with:
> {code}
> 12:51:16,267 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.connection-factory.legacy.InVmConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.connection-factory.legacy.InVmConnectionFactory: WFLYMSGAMQ0082: Unsupported type of connector factory for legacy resource: java.lang.String
> 	at org.wildfly.extension.messaging.activemq.jms.legacy.LegacyConnectionFactoryService.translateFactoryClassName(LegacyConnectionFactoryService.java:311)
> 	at org.wildfly.extension.messaging.activemq.jms.legacy.LegacyConnectionFactoryService.translateTransportGroupConfigurations(LegacyConnectionFactoryService.java:294)
> 	at org.wildfly.extension.messaging.activemq.jms.legacy.LegacyConnectionFactoryService.start(LegacyConnectionFactoryService.java:183)
> 	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_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_51]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
> {code}
> Configuration of connection factory and in-vm connector:
> {code}
> <in-vm-connector name="in-vm" server-id="${my.server-id:0}"/>
> <legacy-connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="${connection-factory.entries.entry:java:/ConnectionFactory}"/>
> {code}
> Problem seems to be that HornetQ connection factory does not accept Artemis InVMConnectorFactory class. 
> As legacy connection factories with in-vm connector cannot be used by standalone JMS client (not serializable) then there is no reason to create them by migration operation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 06:39:00 2015
From: issues at jboss.org (Laurent Pellegrino (JIRA))
Date: Tue, 22 Sep 2015 06:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-248) Constant pool index 268 is
	invalid
In-Reply-To: <JIRA.12577796.1436778937000@Atlassian.JIRA>
References: <JIRA.12577796.1436778937000@Atlassian.JIRA>
	<JIRA.12577796.1436778937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577796.1436778937000.3108.1442918340526@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089134#comment-13089134 ] 

Laurent Pellegrino edited comment on JASSIST-248 at 9/22/15 6:38 AM:
---------------------------------------------------------------------

Shigeru, please find enclosed the class file involved with the issue. It has been retrieved using the `debugDump` option you have mentioned.


was (Author: lpellegr):
Shigeru, please find enclosed the class file involved with the issue. It has been retrieved using the `debugDump` option you have mentioned. I have not yet isolated the issue in a dedicated test. I will try when I have time.

> Constant pool index 268 is invalid
> ----------------------------------
>
>                 Key: JASSIST-248
>                 URL: https://issues.jboss.org/browse/JASSIST-248
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.19.0-GA
>            Reporter: Laurent Pellegrino
>            Assignee: Shigeru Chiba
>              Labels: regression
>         Attachments: _StubLinkedList.class
>
>
> We are using Javassist for one of our open source projects since about 10 years. Recently, I have tried to upgrade to version 3.19 and 3.20. Unfortunately, with both versions, generated byte code seems to cause errors with the JVM.
> Below is the output:
> {code}
> Exception in thread "RestartDownNodesPolicy node status check" java.lang.VerifyError: Illegal type at constant pool entry 268 in class pa.stub.java.util._StubLinkedList
> Exception Details:
>   Location:
>     pa/stub/java/util/_StubLinkedList.replaceAll(Ljava/util/function/UnaryOperator;)V @43: invokespecial
>   Reason:
>     Constant pool index 268 is invalid
>   Bytecode:
>     0x0000000: 2ab4 00cc 9900 252a b400 0db2 002c 100b
>     0x0000010: 32c0 0028 04bd 00ce 5903 2b53 b200 26b8
>     0x0000020: 00d7 b900 dd02 0057 b12a 2bb7 010c b1  
>   Stackmap Table:
>     same_frame(@41)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:264)
> 	at org.objectweb.proactive.core.mop.MOP.forName(MOP.java:155)
> 	at org.objectweb.proactive.core.mop.MOP.findStubConstructor(MOP.java:649)
> 	at org.objectweb.proactive.core.mop.MOP.createStubObject(MOP.java:822)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:338)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:196)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reifyAsAsynchronous(AbstractBodyProxy.java:277)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.invokeOnBody(AbstractBodyProxy.java:154)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reify(AbstractBodyProxy.java:123)
> 	at pa.stub.org.ow2.proactive.resourcemanager.nodesource._StubNodeSource.getDownNodes(_StubNodeSource.java)
> 	at org.ow2.proactive.resourcemanager.nodesource.policy.RestartDownNodesPolicy$1.run(RestartDownNodesPolicy.java:92)
> 	at java.util.TimerThread.mainLoop(Timer.java:555)
> 	at java.util.TimerThread.run(Timer.java:505)
> {code}
> The issue seems related to default methods introduced in Java 8. Perhaps its not an issue with Javassist but to be honest I don't understand the exception.  However, I have noticed that using Javassist in version 3.18.2 solves the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 06:40:00 2015
From: issues at jboss.org (Laurent Pellegrino (JIRA))
Date: Tue, 22 Sep 2015 06:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-248) Constant pool index 268 is
	invalid
In-Reply-To: <JIRA.12577796.1436778937000@Atlassian.JIRA>
References: <JIRA.12577796.1436778937000@Atlassian.JIRA>
	<JIRA.12577796.1436778937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577796.1436778937000.3111.1442918400222@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111179#comment-13111179 ] 

Laurent Pellegrino commented on JASSIST-248:
--------------------------------------------

[~chiba] Do you have an idea about what could be the cause of the error I get?

> Constant pool index 268 is invalid
> ----------------------------------
>
>                 Key: JASSIST-248
>                 URL: https://issues.jboss.org/browse/JASSIST-248
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.19.0-GA
>            Reporter: Laurent Pellegrino
>            Assignee: Shigeru Chiba
>              Labels: regression
>         Attachments: _StubLinkedList.class
>
>
> We are using Javassist for one of our open source projects since about 10 years. Recently, I have tried to upgrade to version 3.19 and 3.20. Unfortunately, with both versions, generated byte code seems to cause errors with the JVM.
> Below is the output:
> {code}
> Exception in thread "RestartDownNodesPolicy node status check" java.lang.VerifyError: Illegal type at constant pool entry 268 in class pa.stub.java.util._StubLinkedList
> Exception Details:
>   Location:
>     pa/stub/java/util/_StubLinkedList.replaceAll(Ljava/util/function/UnaryOperator;)V @43: invokespecial
>   Reason:
>     Constant pool index 268 is invalid
>   Bytecode:
>     0x0000000: 2ab4 00cc 9900 252a b400 0db2 002c 100b
>     0x0000010: 32c0 0028 04bd 00ce 5903 2b53 b200 26b8
>     0x0000020: 00d7 b900 dd02 0057 b12a 2bb7 010c b1  
>   Stackmap Table:
>     same_frame(@41)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:264)
> 	at org.objectweb.proactive.core.mop.MOP.forName(MOP.java:155)
> 	at org.objectweb.proactive.core.mop.MOP.findStubConstructor(MOP.java:649)
> 	at org.objectweb.proactive.core.mop.MOP.createStubObject(MOP.java:822)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:338)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:196)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reifyAsAsynchronous(AbstractBodyProxy.java:277)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.invokeOnBody(AbstractBodyProxy.java:154)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reify(AbstractBodyProxy.java:123)
> 	at pa.stub.org.ow2.proactive.resourcemanager.nodesource._StubNodeSource.getDownNodes(_StubNodeSource.java)
> 	at org.ow2.proactive.resourcemanager.nodesource.policy.RestartDownNodesPolicy$1.run(RestartDownNodesPolicy.java:92)
> 	at java.util.TimerThread.mainLoop(Timer.java:555)
> 	at java.util.TimerThread.run(Timer.java:505)
> {code}
> The issue seems related to default methods introduced in Java 8. Perhaps its not an issue with Javassist but to be honest I don't understand the exception.  However, I have noticed that using Javassist in version 3.18.2 solves the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 07:08:00 2015
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 22 Sep 2015 07:08:00 -0400 (EDT)
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.3228.1442920080350@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111191#comment-13111191 ] 

Peter Skopek commented on ELY-283:
----------------------------------

h1. How to setup gssproxy and Elytron: A brain dump

h2. Notes
According to \[1\] gssproxy is using libgssapi Interposer Plugin which utilises feature of dynamic linker in the system.
It allows to call your library with the same funcion before actual library provided by system. For more info see \[3\].


h2. Versions
h3. Java (client and server): 
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
h3. gssproxy:
gssproxy-0.4.1-1.fc22.x86_64
- using Apache DS (embedded) as KDC

h2. Configurations
{panel:title=/root/gssproxy.conf}
{noformat}
[gssproxy]

[service/eap]
  mechs = krb5
  cred_store = keytab:/opt/keytab/serverKeyTab-apache
#  cred_store = keytab:/opt/keytab/serverKeyTab
#  cred_store = keytab:/root/serverKeyTab
  allow_any_uid = yes
  trusted = yes
  euid = 12956   # UID os the user running process which accesses gssproxy
  krb5_principal = sasl/test_server_1 at WILDFLY.ORG{quote}
{noformat}{panel}

Start gssproxy under root as follows: /sbin/gssproxy -i -d -c /root/gssproxy.conf
- interactive run
- debug
- using following configuration
- no need to stop original /sbin/gssproxy process unless one is using the same euid in both configurations

{panel:title=krb5.conf used by Java Server process (part of source code of Elytron)}
{noformat}
[libdefaults]
	default_realm = WILDFLY.ORG
	default_tgs_enctypes = des-cbc-md5,des3-cbc-sha1-kd
	default_tkt_enctypes = des-cbc-md5,des3-cbc-sha1-kd
	kdc_timeout = 5000
	dns_lookup_realm = false
	dns_lookup_kdc = false
	allow_weak_crypto = yes
	forwardable = true

[realms]
	WILDFLY.ORG = {
		kdc = localhost:6088
	}

[login]
	krb4_convert = true
	krb4_get_tickets = false
{noformat}{panel}

{panel:title=/etc/krb5.conf used by Java Client process}
{noformat}
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = WILDFLY.ORG
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
WILDFLY.ORG = {
   kdc = 127.0.0.1:6088
}

[domain_realm]
.redhat.com = REDHAT.COM  
redhat.com = REDHAT.COM
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
{noformat}{panel}

h2. To read:

\[1\] https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/docs/Behavior
\[2\] https://fedorahosted.org/gss-proxy/
\[3\] http://www.drdobbs.com/building-library-interposers-for-fun-and/184404926


h2. Java Server Process (using gssproxy) VM options
-Djavax.security.auth.useSubjectCredsOnly=false 
-Dsun.security.jgss.lib="/usr/lib64/libgssapi_krb5.so.2.2" 
-Dsun.security.jgss.native="true" 
-Dsun.security.krb5.debug=true 
-Dsun.security.jgss.debug=true

h2. Environment variables for the sever process
- GSSPROXY_BEHAVIOR=REMOTE_FIRST 
- GSS_USE_PROXY=1

h2. Java Client Process (not using gssproxy) VM options:
-Dsun.security.krb5.debug=true 
-Dsun.security.jgss.debug=true

_Note: Just debugging stuff._


> 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: Peter Skopek
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 07:15:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 07:15:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-926) Missing synchronization in
 PackageClassLoader causes a LinkageError: duplicate class definition
In-Reply-To: <JIRA.12585639.1442920477000@Atlassian.JIRA>
References: <JIRA.12585639.1442920477000@Atlassian.JIRA>
	<JIRA.12585639.1442920477689@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585639.1442920477000.3296.1442920500061@Atlassian.JIRA>

Mario Fusco created DROOLS-926:
----------------------------------

             Summary: Missing synchronization in PackageClassLoader causes a LinkageError: duplicate class definition
                 Key: DROOLS-926
                 URL: https://issues.jboss.org/browse/DROOLS-926
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


Creating multiple KieSessions from a KieBase with a function and using them concurrently from different threads may lead to the following error

java.util.concurrent.ExecutionException: java.lang.LinkageError: loader (instance of  org/drools/core/rule/JavaDialectRuntimeData$PackageClassLoader): attempted  duplicate class definition for name: "defaultpkg/IsEven"
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:188)
	at org.drools.compiler.integrationtests.Misc2Test.testFunctionInvokingFunction(Misc2Test.java:8191)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.lang.LinkageError: loader (instance of  org/drools/core/rule/JavaDialectRuntimeData$PackageClassLoader): attempted  duplicate class definition for name: "defaultpkg/IsEven"
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:673)
	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:639)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
	at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:214)
	at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:254)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:238)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:204)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298)
	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
	at org.drools.compiler.integrationtests.Misc2Test$11.call(Misc2Test.java:8180)
	at org.drools.compiler.integrationtests.Misc2Test$11.call(Misc2Test.java:8170)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 07:22:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 07:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.3321.1442920920258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-756:
-------------------------------------
    Attachment: server.log


Remoting at trace lavel
Xnio off

> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR3
>
>         Attachments: server.log, server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 07:34:01 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 22 Sep 2015 07:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3964) EJBAccessException is not
 returned to remote client
In-Reply-To: <JIRA.12554771.1412929454000@Atlassian.JIRA>
References: <JIRA.12554771.1412929454000@Atlassian.JIRA>
	<JIRA.12554771.1412929454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554771.1412929454000.3389.1442921641167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111206#comment-13111206 ] 

David Lloyd commented on WFLY-3964:
-----------------------------------

Both sides are "openjdk version "1.8.0_25" OpenJDK Runtime Environment (build 1.8.0_25-b18) OpenJDK 64-Bit Server VM (build 25.25-b02, mixed mode)"
Both sides running 8.1.0.Final libraries, one is standalone app (attached), the other is a server.


> EJBAccessException is not returned to remote client
> ---------------------------------------------------
>
>                 Key: WFLY-3964
>                 URL: https://issues.jboss.org/browse/WFLY-3964
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>            Reporter: Dirk Weil
>            Assignee: Dmitrii Tikhomirov
>
> When calling an EJB method with access restrictions via @RolesAllowed from a remote client with unsufficient user priveledges, an EJBAccessException should be returned to the remote caller. WildFly returns a java.io.StreamCorruptedException instead.
> Stacktrace on client:
> {code}
> java.io.StreamCorruptedException: Unexpected byte found when reading an object: 0
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:236)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> 	at com.sun.proxy.$Proxy6.restrictedMethod(Unknown Source)
> 	at de.gedoplan.beantrial.wildflyejbremote.DemoTest.testRestrictedMethod(DemoTest.java:68)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)
> 	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.io.StreamCorruptedException: Unexpected byte found when reading an object: 0
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:751)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> 	at org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments(ProtocolMessageHandler.java:55)
> 	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:82)
> 	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.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> 	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:202)
> 	... 30 more
> 	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> 	at org.junit.Assert.assertThat(Assert.java:865)
> 	at org.junit.Assert.assertThat(Assert.java:832)
> 	at org.junit.rules.ExpectedException.handleException(ExpectedException.java:198)
> 	at org.junit.rules.ExpectedException.access$500(ExpectedException.java:85)
> 	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:177)
> 	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 07:35:00 2015
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 22 Sep 2015 07:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-292) Sasl server filtering with
	credential names
In-Reply-To: <JIRA.12585626.1442914163000@Atlassian.JIRA>
References: <JIRA.12585626.1442914163000@Atlassian.JIRA>
	<JIRA.12585626.1442914163000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585626.1442914163000.3418.1442921700534@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-292:
---------------------------
    Description: 
Meaning of `FilterMechanismSaslServer` should change, as the way of getting credential was changed. In past it was base on data type of credential, now it is base on credential names.

See* `FilterMechanismSaslServer` constructor (filtering part commented out for now)
https://github.com/wildfly-security/wildfly-elytron/commit/1e32ef5a0033c3e20f776a12ebcad0775dcf7b67#diff-ff46d10f5f522391f72d789ed37fbc72R47

  was:
Meaning of `FilterMechanismSaslServer` should change, as the way of getting credential was changed. In past it was base on data type of credential, now it is base on credential names.

See* `FilterMechanismSaslServer` constructor (filtering part commented out for now)



> Sasl server filtering with credential names
> -------------------------------------------
>
>                 Key: ELY-292
>                 URL: https://issues.jboss.org/browse/ELY-292
>             Project: WildFly Elytron
>          Issue Type: Task
>            Reporter: Jan Kalina
>
> Meaning of `FilterMechanismSaslServer` should change, as the way of getting credential was changed. In past it was base on data type of credential, now it is base on credential names.
> See* `FilterMechanismSaslServer` constructor (filtering part commented out for now)
> https://github.com/wildfly-security/wildfly-elytron/commit/1e32ef5a0033c3e20f776a12ebcad0775dcf7b67#diff-ff46d10f5f522391f72d789ed37fbc72R47



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 07:54:00 2015
From: issues at jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 22 Sep 2015 07:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5381) Fix pom.xml jpda profile and
 add ability to specify additional surefire forked JVM args via command line
In-Reply-To: <JIRA.12585645.1442922795000@Atlassian.JIRA>
References: <JIRA.12585645.1442922795000@Atlassian.JIRA>
	<JIRA.12585645.1442922795189@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585645.1442922795000.3534.1442922840215@Atlassian.JIRA>

Dominik Pospisil created WFLY-5381:
--------------------------------------

             Summary: Fix pom.xml jpda profile and add ability to specify additional surefire forked JVM args via command line
                 Key: WFLY-5381
                 URL: https://issues.jboss.org/browse/WFLY-5381
             Project: WildFly
          Issue Type: Bug
          Components: Build System
    Affects Versions: 10.0.0.CR1
            Reporter: Dominik Pospisil
            Assignee: Dominik Pospisil


mvn install -Pjpda should run the tests with debugging enabled but it does not as the surefire.jpda.args property is ignored.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 08:30:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 08:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5382) XML descriptors don't work in
 static deployment.
In-Reply-To: <JIRA.12585253.1442497519000@Atlassian.JIRA>
References: <JIRA.12585253.1442497519000@Atlassian.JIRA>
	<JIRA.12585253.1442497519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585253.1442497519000.3764.1442925000561@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBCL-187 to WFLY-5382:
----------------------------------------

        Project: WildFly  (was: JBoss ClassLoader)
            Key: WFLY-5382  (was: JBCL-187)
       Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Component/s: CDI / Weld
                 Class Loading
                     (was: ClassLoader)


> XML descriptors don't work in static deployment.
> ------------------------------------------------
>
>                 Key: WFLY-5382
>                 URL: https://issues.jboss.org/browse/WFLY-5382
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Class Loading
>            Reporter: Danila  Sofinskii
>            Assignee: Ales Justin
>
> I have one module with stateless EJB bean and two configuration files - persistence.xml and ejb-jar.xml in META-INF.
> I try to deploy it in static context with jar index, created by Jandex, inside. For depends dynamically deployed modules I wrote 'Dependencies: core.module.name annotations' to manifest file, like in this issue: https://issues.jboss.org/browse/WFLY-4386
> My bean found by WELD, but it can't take xml files - Persistence Context, which I configure in persistence.xml, not found, and Module Name from ejb-jar.xml are wrong, too.
> How I can configure module for work with this xml files?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 08:31:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 08:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5382) XML descriptors don't work in
 static deployment.
In-Reply-To: <JIRA.12585253.1442497519000@Atlassian.JIRA>
References: <JIRA.12585253.1442497519000@Atlassian.JIRA>
	<JIRA.12585253.1442497519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585253.1442497519000.3770.1442925060137@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111241#comment-13111241 ] 

Tomaz Cerar commented on WFLY-5382:
-----------------------------------

What version of WildFly are you using?

> XML descriptors don't work in static deployment.
> ------------------------------------------------
>
>                 Key: WFLY-5382
>                 URL: https://issues.jboss.org/browse/WFLY-5382
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Class Loading
>            Reporter: Danila  Sofinskii
>            Assignee: Ales Justin
>
> I have one module with stateless EJB bean and two configuration files - persistence.xml and ejb-jar.xml in META-INF.
> I try to deploy it in static context with jar index, created by Jandex, inside. For depends dynamically deployed modules I wrote 'Dependencies: core.module.name annotations' to manifest file, like in this issue: https://issues.jboss.org/browse/WFLY-4386
> My bean found by WELD, but it can't take xml files - Persistence Context, which I configure in persistence.xml, not found, and Module Name from ejb-jar.xml are wrong, too.
> How I can configure module for work with this xml files?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 08:33:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 08:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5381) Fix pom.xml jpda profile and
 add ability to specify additional surefire forked JVM args via command line
In-Reply-To: <JIRA.12585645.1442922795000@Atlassian.JIRA>
References: <JIRA.12585645.1442922795000@Atlassian.JIRA>
	<JIRA.12585645.1442922795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585645.1442922795000.3782.1442925180095@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-5381:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1265229
        Bugzilla Update: Perform


> Fix pom.xml jpda profile and add ability to specify additional surefire forked JVM args via command line
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5381
>                 URL: https://issues.jboss.org/browse/WFLY-5381
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.0.0.CR1
>            Reporter: Dominik Pospisil
>            Assignee: Dominik Pospisil
>
> mvn install -Pjpda should run the tests with debugging enabled but it does not as the surefire.jpda.args property is ignored.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 08:36:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 22 Sep 2015 08:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-923) Execution timeout for CLI
	operations
In-Reply-To: <JIRA.12582757.1440656755000@Atlassian.JIRA>
References: <JIRA.12582757.1440656755000@Atlassian.JIRA>
	<JIRA.12582757.1440656755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582757.1440656755000.3789.1442925360160@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111245#comment-13111245 ] 

Alexey Loubyansky commented on WFCORE-923:
------------------------------------------

Thanks for the details. It looks like it is possible to implement in the CLI a timeout for an operation request. Although, in case of batches (or single commands that translate into a composite operation) I am not sure we'll be able to tell at which step the composite operation got stuck though.

> Execution timeout for CLI operations
> ------------------------------------
>
>                 Key: WFCORE-923
>                 URL: https://issues.jboss.org/browse/WFCORE-923
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Lyle Wang
>            Assignee: Alexey Loubyansky
>              Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy"  inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 09:43:00 2015
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 22 Sep 2015 09:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335955@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4140.1442929380802@Atlassian.JIRA>

Rostislav Svoboda created WFLY-5383:
---------------------------------------

             Summary: xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
                 Key: WFLY-5383
                 URL: https://issues.jboss.org/browse/WFLY-5383
             Project: WildFly
          Issue Type: Bug
          Components: Web Services
            Reporter: Rostislav Svoboda
            Assignee: Alessio Soldano


EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.

Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 

I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.

For now I created just one JIRA, can split it into more if needed.

Here is the list of problematic files:
{code}
 === datatypes.dtd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
[jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
[jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
[picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
[xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
[cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
[wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
[jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
[jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
[opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
{code}
{code}
 === ietf-kitten-sasl-saml-ec.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
[opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
{code}
{code}
 === soap-envelope.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
[opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
{code}
{code}
 === sstc-metadata-attr.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
[opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
{code}
{code}
 === sstc-saml-delegation.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
[opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
{code}
{code}
 === sstc-saml-idp-discovery.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
[opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
{code}
{code}
 === sstc-saml-metadata-ext-query.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
[opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
{code}
{code}
 === sstc-saml-protocol-ext-thirdparty.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
[opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
{code}
{code}
 === ws-addr.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
[picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
[cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
[jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
[jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
[jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
[jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
[opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
{code}
{code}
 === ws-policy.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
[picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
[opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
{code}
{code}
 === xenc-schema.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
[picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
[xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
[xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
[wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
[opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
{code}
{code}
 === xmldsig-core-schema.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
[picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
[xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
[xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
[cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
[wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
[opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
{code}
{code}
 === XMLSchema.dtd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
[jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
[jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
[picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
[xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
[cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
[wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
[jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
[jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
[opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
{code}
{code}
 === XMLSchema.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
[cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
[opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
{code}
{code}
 === xmltooling-config.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
[opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
{code}
{code}
 === xml.xsd ===
-rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
[jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
[jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
[picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
[xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
[cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
[cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
[wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
[jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
[opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 09:43:01 2015
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Tue, 22 Sep 2015 09:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-829) Content repo gc task can
 delete content in mid-upload
In-Reply-To: <JIRA.12578450.1437142209000@Atlassian.JIRA>
References: <JIRA.12578450.1437142209000@Atlassian.JIRA>
	<JIRA.12578450.1437142209000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578450.1437142209000.4151.1442929381095@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reopened WFCORE-829:
-------------------------------


> Content repo gc task can delete content in mid-upload
> -----------------------------------------------------
>
>                 Key: WFCORE-829
>                 URL: https://issues.jboss.org/browse/WFCORE-829
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha10
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>
> Description of problem:
> if upload of an application takes more than 5 minutes, it is removed from repository by clean-obsolete-content.
> - start the upload
> [Host Controller] 15:44:05,456 INFO  [org.jboss.as.repository] (HttpManagementService-threads - 1) JBAS014900: Content added at location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> - After 5 minutes, the content is removed:
> [Host Controller] 15:49:32,111 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014903: Content /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64 is obsolete and will be removed
> [Host Controller] 15:49:32,113 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014901: Content removed from location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> The reference for the deployment is added to domain.xml only after the upload is finished. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 09:47:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 09:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.4170.1442929620164@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111289#comment-13111289 ] 

Tomaz Cerar commented on WFCORE-715:
------------------------------------

Sent pull request with more appropriate fix.

> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Tomaz Cerar
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:05:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 10:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4244.1442930700157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-5383:
------------------------------
    Component/s: Build System
                     (was: Web Services)


> xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5383
>                 URL: https://issues.jboss.org/browse/WFLY-5383
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Rostislav Svoboda
>            Assignee: Alessio Soldano
>
> EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.
> Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 
> I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.
> For now I created just one JIRA, can split it into more if needed.
> Here is the list of problematic files:
> {code}
>  === datatypes.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
> [picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
> [xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
> [jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
> [opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
> {code}
> {code}
>  === ietf-kitten-sasl-saml-ec.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
> [opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
> {code}
> {code}
>  === soap-envelope.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
> [opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
> {code}
> {code}
>  === sstc-metadata-attr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
> [opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
> {code}
> {code}
>  === sstc-saml-delegation.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
> [opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
> {code}
> {code}
>  === sstc-saml-idp-discovery.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
> [opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
> {code}
> {code}
>  === sstc-saml-metadata-ext-query.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
> [opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
> {code}
> {code}
>  === sstc-saml-protocol-ext-thirdparty.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
> [opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
> {code}
> {code}
>  === ws-addr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
> [opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
> {code}
> {code}
>  === ws-policy.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
> [opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
> {code}
> {code}
>  === xenc-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
> {code}
> {code}
>  === xmldsig-core-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
> {code}
> {code}
>  === XMLSchema.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
> [picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
> [xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
> [jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
> [opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
> {code}
> {code}
>  === XMLSchema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
> [opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
> {code}
> {code}
>  === xmltooling-config.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
> [opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
> {code}
> {code}
>  === xml.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
> [jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
> [picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
> [xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
> [jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
> [opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:05:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 10:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4248.1442930700288@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111300#comment-13111300 ] 

Tomaz Cerar commented on WFLY-5383:
-----------------------------------

This is mostly build tool / plugin issue.

> xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5383
>                 URL: https://issues.jboss.org/browse/WFLY-5383
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Rostislav Svoboda
>            Assignee: Alessio Soldano
>
> EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.
> Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 
> I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.
> For now I created just one JIRA, can split it into more if needed.
> Here is the list of problematic files:
> {code}
>  === datatypes.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
> [picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
> [xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
> [jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
> [opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
> {code}
> {code}
>  === ietf-kitten-sasl-saml-ec.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
> [opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
> {code}
> {code}
>  === soap-envelope.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
> [opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
> {code}
> {code}
>  === sstc-metadata-attr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
> [opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
> {code}
> {code}
>  === sstc-saml-delegation.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
> [opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
> {code}
> {code}
>  === sstc-saml-idp-discovery.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
> [opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
> {code}
> {code}
>  === sstc-saml-metadata-ext-query.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
> [opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
> {code}
> {code}
>  === sstc-saml-protocol-ext-thirdparty.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
> [opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
> {code}
> {code}
>  === ws-addr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
> [opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
> {code}
> {code}
>  === ws-policy.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
> [opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
> {code}
> {code}
>  === xenc-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
> {code}
> {code}
>  === xmldsig-core-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
> {code}
> {code}
>  === XMLSchema.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
> [picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
> [xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
> [jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
> [opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
> {code}
> {code}
>  === XMLSchema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
> [opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
> {code}
> {code}
>  === xmltooling-config.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
> [opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
> {code}
> {code}
>  === xml.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
> [jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
> [picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
> [xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
> [jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
> [opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:11:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Sep 2015 10:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4264.1442931060322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-5383:
---------------------------------

    Assignee: Tomaz Cerar  (was: Alessio Soldano)


> xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5383
>                 URL: https://issues.jboss.org/browse/WFLY-5383
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Rostislav Svoboda
>            Assignee: Tomaz Cerar
>
> EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.
> Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 
> I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.
> For now I created just one JIRA, can split it into more if needed.
> Here is the list of problematic files:
> {code}
>  === datatypes.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
> [picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
> [xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
> [jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
> [opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
> {code}
> {code}
>  === ietf-kitten-sasl-saml-ec.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
> [opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
> {code}
> {code}
>  === soap-envelope.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
> [opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
> {code}
> {code}
>  === sstc-metadata-attr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
> [opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
> {code}
> {code}
>  === sstc-saml-delegation.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
> [opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
> {code}
> {code}
>  === sstc-saml-idp-discovery.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
> [opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
> {code}
> {code}
>  === sstc-saml-metadata-ext-query.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
> [opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
> {code}
> {code}
>  === sstc-saml-protocol-ext-thirdparty.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
> [opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
> {code}
> {code}
>  === ws-addr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
> [opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
> {code}
> {code}
>  === ws-policy.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
> [opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
> {code}
> {code}
>  === xenc-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
> {code}
> {code}
>  === xmldsig-core-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
> {code}
> {code}
>  === XMLSchema.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
> [picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
> [xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
> [jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
> [opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
> {code}
> {code}
>  === XMLSchema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
> [opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
> {code}
> {code}
>  === xmltooling-config.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
> [opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
> {code}
> {code}
>  === xml.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
> [jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
> [picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
> [xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
> [jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
> [opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:15:01 2015
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 22 Sep 2015 10:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4281.1442931301242@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111305#comment-13111305 ] 

Rostislav Svoboda commented on WFLY-5383:
-----------------------------------------

To give you full picture, there are not only these files, but directories too :)
Wanna separe JIRA for it or will you handle it within this one ?

{code}
wstrust
wstrust/v1_3
w3c
w3c/xmlenc
w3c/xmldsig
w3c/xmlschema
xmlschema
liberty
liberty/idwsf
saml
saml/v1
saml/v2
{code}

> xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5383
>                 URL: https://issues.jboss.org/browse/WFLY-5383
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Rostislav Svoboda
>            Assignee: Tomaz Cerar
>
> EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.
> Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 
> I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.
> For now I created just one JIRA, can split it into more if needed.
> Here is the list of problematic files:
> {code}
>  === datatypes.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
> [picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
> [xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
> [jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
> [opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
> {code}
> {code}
>  === ietf-kitten-sasl-saml-ec.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
> [opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
> {code}
> {code}
>  === soap-envelope.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
> [opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
> {code}
> {code}
>  === sstc-metadata-attr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
> [opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
> {code}
> {code}
>  === sstc-saml-delegation.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
> [opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
> {code}
> {code}
>  === sstc-saml-idp-discovery.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
> [opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
> {code}
> {code}
>  === sstc-saml-metadata-ext-query.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
> [opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
> {code}
> {code}
>  === sstc-saml-protocol-ext-thirdparty.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
> [opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
> {code}
> {code}
>  === ws-addr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
> [opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
> {code}
> {code}
>  === ws-policy.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
> [opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
> {code}
> {code}
>  === xenc-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
> {code}
> {code}
>  === xmldsig-core-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
> {code}
> {code}
>  === XMLSchema.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
> [picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
> [xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
> [jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
> [opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
> {code}
> {code}
>  === XMLSchema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
> [opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
> {code}
> {code}
>  === xmltooling-config.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
> [opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
> {code}
> {code}
>  === xml.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
> [jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
> [picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
> [xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
> [jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
> [opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:16:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 22 Sep 2015 10:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5384) Validate Artemis parameters
In-Reply-To: <JIRA.12585667.1442931350000@Atlassian.JIRA>
References: <JIRA.12585667.1442931350000@Atlassian.JIRA>
	<JIRA.12585667.1442931350544@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585667.1442931350000.4286.1442931360162@Atlassian.JIRA>

Jeff Mesnil created WFLY-5384:
---------------------------------

             Summary: Validate Artemis parameters 
                 Key: WFLY-5384
                 URL: https://issues.jboss.org/browse/WFLY-5384
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 10.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 10.0.0.CR2


Artemis changed the naming convention to use CamelCase for its acceptor and connector parameters keys.
Validation of the parameters was discarded when the messaging-activemq subsystem was created.
This means that the current template for the messaging-activemq subsystem is not correct (the parameters will not be taken into account by Artemis).
The server-id parameter for in-vm connector has also be renamed to serverId. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:19:00 2015
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 22 Sep 2015 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4295.1442931540264@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111306#comment-13111306 ] 

Rostislav Svoboda commented on WFLY-5383:
-----------------------------------------

These are mainly from picketlink-federation-2.5.5.CR1.jar.

> xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5383
>                 URL: https://issues.jboss.org/browse/WFLY-5383
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Rostislav Svoboda
>            Assignee: Tomaz Cerar
>
> EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.
> Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 
> I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.
> For now I created just one JIRA, can split it into more if needed.
> Here is the list of problematic files:
> {code}
>  === datatypes.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
> [picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
> [xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
> [jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
> [opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
> {code}
> {code}
>  === ietf-kitten-sasl-saml-ec.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
> [opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
> {code}
> {code}
>  === soap-envelope.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
> [opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
> {code}
> {code}
>  === sstc-metadata-attr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
> [opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
> {code}
> {code}
>  === sstc-saml-delegation.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
> [opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
> {code}
> {code}
>  === sstc-saml-idp-discovery.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
> [opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
> {code}
> {code}
>  === sstc-saml-metadata-ext-query.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
> [opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
> {code}
> {code}
>  === sstc-saml-protocol-ext-thirdparty.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
> [opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
> {code}
> {code}
>  === ws-addr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
> [opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
> {code}
> {code}
>  === ws-policy.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
> [opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
> {code}
> {code}
>  === xenc-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
> {code}
> {code}
>  === xmldsig-core-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
> {code}
> {code}
>  === XMLSchema.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
> [picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
> [xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
> [jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
> [opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
> {code}
> {code}
>  === XMLSchema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
> [opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
> {code}
> {code}
>  === xmltooling-config.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
> [opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
> {code}
> {code}
>  === xml.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
> [jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
> [picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
> [xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
> [jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
> [opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:19:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 22 Sep 2015 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5384) Validate Artemis parameters
In-Reply-To: <JIRA.12585667.1442931350000@Atlassian.JIRA>
References: <JIRA.12585667.1442931350000@Atlassian.JIRA>
	<JIRA.12585667.1442931350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585667.1442931350000.4297.1442931540298@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5384:
------------------------------
    Priority: Critical  (was: Major)


> Validate Artemis parameters 
> ----------------------------
>
>                 Key: WFLY-5384
>                 URL: https://issues.jboss.org/browse/WFLY-5384
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Artemis changed the naming convention to use CamelCase for its acceptor and connector parameters keys.
> Validation of the parameters was discarded when the messaging-activemq subsystem was created.
> This means that the current template for the messaging-activemq subsystem is not correct (the parameters will not be taken into account by Artemis).
> The server-id parameter for in-vm connector has also be renamed to serverId. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:22:00 2015
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 22 Sep 2015 10:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4314.1442931720159@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111308#comment-13111308 ] 

Rostislav Svoboda commented on WFLY-5383:
-----------------------------------------

One additional thing - I was checking xsd/dtd files without version - that was the initial trigger.
But there are files like saml-schema-authn-context-ippword-2.0.xsd which shouldn't be probably in docs/schema

{code}
saml-async-slo-v1.0.xsd                                  saml-schema-authn-context-nomad-telephony-2.0.xsd        saml-schema-authn-context-telephony-2.0.xsd
saml-metadata-rpi-v1.0.xsd                               saml-schema-authn-context-personal-telephony-2.0.xsd     saml-schema-authn-context-timesync-2.0.xsd
saml-schema-assertion-2.0.xsd                            saml-schema-authn-context-pgp-2.0.xsd                    saml-schema-authn-context-types-2.0.xsd
saml-schema-authn-context-2.0.xsd                        saml-schema-authn-context-ppt-2.0.xsd                    saml-schema-authn-context-x509-2.0.xsd
saml-schema-authn-context-auth-telephony-2.0.xsd         saml-schema-authn-context-pword-2.0.xsd                  saml-schema-authn-context-xmldsig-2.0.xsd
saml-schema-authn-context-ip-2.0.xsd                     saml-schema-authn-context-session-2.0.xsd                saml-schema-dce-2.0.xsd
saml-schema-authn-context-ippword-2.0.xsd                saml-schema-authn-context-smartcard-2.0.xsd              saml-schema-ecp-2.0.xsd
saml-schema-authn-context-kerberos-2.0.xsd               saml-schema-authn-context-smartcardpki-2.0.xsd           saml-schema-metadata-2.0.xsd
saml-schema-authn-context-mobileonefactor-reg-2.0.xsd    saml-schema-authn-context-softwarepki-2.0.xsd            saml-schema-protocol-2.0.xsd
saml-schema-authn-context-mobileonefactor-unreg-2.0.xsd  saml-schema-authn-context-spki-2.0.xsd                   saml-schema-x500-2.0.xsd
saml-schema-authn-context-mobiletwofactor-reg-2.0.xsd    saml-schema-authn-context-srp-2.0.xsd                    saml-schema-xacml-2.0.xsd
saml-schema-authn-context-mobiletwofactor-unreg-2.0.xsd  saml-schema-authn-context-sslcert-2.0.xsd                
{code}
These are from opensaml-saml-api-3.1.1.jar

Definitely more to find :)

> xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5383
>                 URL: https://issues.jboss.org/browse/WFLY-5383
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Rostislav Svoboda
>            Assignee: Tomaz Cerar
>
> EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.
> Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 
> I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.
> For now I created just one JIRA, can split it into more if needed.
> Here is the list of problematic files:
> {code}
>  === datatypes.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
> [picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
> [xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
> [jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
> [opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
> {code}
> {code}
>  === ietf-kitten-sasl-saml-ec.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
> [opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
> {code}
> {code}
>  === soap-envelope.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
> [opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
> {code}
> {code}
>  === sstc-metadata-attr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
> [opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
> {code}
> {code}
>  === sstc-saml-delegation.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
> [opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
> {code}
> {code}
>  === sstc-saml-idp-discovery.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
> [opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
> {code}
> {code}
>  === sstc-saml-metadata-ext-query.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
> [opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
> {code}
> {code}
>  === sstc-saml-protocol-ext-thirdparty.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
> [opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
> {code}
> {code}
>  === ws-addr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
> [opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
> {code}
> {code}
>  === ws-policy.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
> [opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
> {code}
> {code}
>  === xenc-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
> {code}
> {code}
>  === xmldsig-core-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
> {code}
> {code}
>  === XMLSchema.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
> [picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
> [xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
> [jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
> [opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
> {code}
> {code}
>  === XMLSchema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
> [opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
> {code}
> {code}
>  === xmltooling-config.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
> [opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
> {code}
> {code}
>  === xml.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
> [jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
> [picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
> [xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
> [jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
> [opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:36:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Tue, 22 Sep 2015 10:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5152) Subsystem iiop-openjdk should
 define port bindings in default configuration
In-Reply-To: <JIRA.12582093.1440143946000@Atlassian.JIRA>
References: <JIRA.12582093.1440143946000@Atlassian.JIRA>
	<JIRA.12582093.1440143946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582093.1440143946000.4357.1442932560167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111316#comment-13111316 ] 

Tomasz Adamski commented on WFLY-5152:
--------------------------------------

TODO: https://github.com/wildfly/wildfly/pull/8151#issuecomment-142302446

> Subsystem iiop-openjdk should define port bindings in default configuration
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5152
>                 URL: https://issues.jboss.org/browse/WFLY-5152
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Minor
>
> Default configuration that is shipped with EAP/WFLY for iiop-openjdk subsystem does not contain port binding. This could be a bit confusing for users when looking on configuration file and if they check for strings/ports {{iiop}} and {{iiop-ssl}} they are not mentioned in configuration file. Course the name suggests what they are for but I think that configuration file should avoid such implicit usage which came from default values settings.
> JacORB subsystem in EAP 6.4 looked like
> {code}
>         <subsystem xmlns="urn:jboss:domain:jacorb:1.4">
>             <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
>                 <initializers transactions="spec" security="identity"/>
>             </orb>
>         </subsystem>
> {code}
> I think that the IIOP OpenJDK subsystem should define the socket binding as well. I mean instead of
> {code}
>         <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
>             <initializers transactions="spec" security="identity"/>
>         </subsystem>
> {code}
> the default configuration could be
> {code}
>         <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
>             <orb ssl-socket-binding=\"iiop-ssl\" socket-binding=\"iiop\"/>
>             <initializers transactions="spec" security="identity"/>
>         </subsystem>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 22 10:36:00 2015
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 22 Sep 2015 10:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5383) xsd/dtd files in docs/schema
 not related to management,
 mainly from opensaml and othr cxf related artifacts
In-Reply-To: <JIRA.12585664.1442929335000@Atlassian.JIRA>
References: <JIRA.12585664.1442929335000@Atlassian.JIRA>
	<JIRA.12585664.1442929335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585664.1442929335000.4361.1442932560305@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rostislav Svoboda updated WFLY-5383:
------------------------------------
    Steps to Reproduce: 
{code}
JBOSS_HOME=/foo/bar
JAR_LOCATION=${JBOSS_HOME}/modules

rm -f jar-list && for i in `find ${JAR_LOCATION} | grep jar$ `; do echo $i; FILE_NAME=`basename $i`; unzip -l $i | while read out_line; do echo "[${FILE_NAME}] ${out_line}"; done >> jar-list;  done
{code}

{code}
ARRAY=( 
datatypes.dtd
ietf-kitten-sasl-saml-ec.xsd
soap-envelope.xsd
sstc-metadata-attr.xsd
sstc-saml-delegation.xsd
sstc-saml-idp-discovery.xsd
sstc-saml-metadata-ext-query.xsd
sstc-saml-protocol-ext-thirdparty.xsd
ws-addr.xsd
ws-policy.xsd
xenc-schema.xsd
xmldsig-core-schema.xsd
XMLSchema.dtd
XMLSchema.xsd
xmltooling-config.xsd
xml.xsd
      )
{code}
{code}
for line in "${ARRAY[@]}" ; do
  echo ""
  echo " === ${line} ==="
  ls -l ${JBOSS_HOME}/docs/schema/${line}
  grep "/${line}" jar-list
done
{code}


> xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5383
>                 URL: https://issues.jboss.org/browse/WFLY-5383
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Rostislav Svoboda
>            Assignee: Tomaz Cerar
>
> EAP 7 DR10 build and Wildfly 10 contains xsd/dtd files in docs/schema not related to management, mainly from opensaml and othr cxf related artifacts.
> Seems like these files are extracted from jars during the build. Based on file size it seems all the files I focused on are from opensaml jars. 
> I'm really not sure we need these xsd/dtd files in docs/schema directory. I would suggest to drop them or split the content of docs/schema to WF10/EAP7management related and the rest.
> For now I created just one JIRA, can split it into more if needed.
> Here is the list of problematic files:
> {code}
>  === datatypes.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 6357 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/datatypes.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 8298  07-29-2015 11:31   com/sun/faces/datatypes.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 6367  10-09-2013 15:30   javax/servlet/resources/datatypes.dtd
> [picketlink-federation-2.5.5.CR1.jar] 7803  08-25-2015 13:19   schema/w3c/xmlschema/datatypes.dtd
> [xmlsec-2.0.5.jar] 6357  07-10-2015 13:51   bindings/schemas/datatypes.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 6357  05-14-2015 15:00   schemas/datatypes.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 6357  07-14-2015 17:09   schemas/datatypes.dtd
> [jbossxacml-2.0.8.Final.jar] 6562  04-04-2012 10:01   schema/xmlschema/datatypes.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 6562  09-16-2015 09:18   dtd/datatypes.dtd
> [opensaml-core-3.1.1.jar] 6357  03-25-2015 14:19   schema/datatypes.dtd
> {code}
> {code}
>  === ietf-kitten-sasl-saml-ec.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1391 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ietf-kitten-sasl-saml-ec.xsd
> [opensaml-saml-api-3.1.1.jar] 1391  03-25-2015 14:20   schema/ietf-kitten-sasl-saml-ec.xsd
> {code}
> {code}
>  === soap-envelope.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 4607 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/soap-envelope.xsd
> [opensaml-soap-api-3.1.1.jar] 4607  03-25-2015 14:20   schema/soap-envelope.xsd
> {code}
> {code}
>  === sstc-metadata-attr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1161 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-metadata-attr.xsd
> [opensaml-saml-api-3.1.1.jar] 1161  03-25-2015 14:20   schema/sstc-metadata-attr.xsd
> {code}
> {code}
>  === sstc-saml-delegation.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1631 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-delegation.xsd
> [opensaml-saml-api-3.1.1.jar] 1631  03-25-2015 14:20   schema/sstc-saml-delegation.xsd
> {code}
> {code}
>  === sstc-saml-idp-discovery.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 982 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-idp-discovery.xsd
> [opensaml-saml-api-3.1.1.jar] 982  03-25-2015 14:20   schema/sstc-saml-idp-discovery.xsd
> {code}
> {code}
>  === sstc-saml-metadata-ext-query.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2321 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-metadata-ext-query.xsd
> [opensaml-saml-api-3.1.1.jar] 2321  03-25-2015 14:20   schema/sstc-saml-metadata-ext-query.xsd
> {code}
> {code}
>  === sstc-saml-protocol-ext-thirdparty.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 1001 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/sstc-saml-protocol-ext-thirdparty.xsd
> [opensaml-saml-api-3.1.1.jar] 1001  03-25-2015 14:20   schema/sstc-saml-protocol-ext-thirdparty.xsd
> {code}
> {code}
>  === ws-addr.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5574 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-addr.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5800  08-25-2015 13:19   schema/wstrust/v1_3/ws-addr.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5591  08-31-2015 16:21   schemas/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   wscoor1.1/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/ws-addr.xsd
> [jbossxts-5.2.2.Final.jar] 5581  08-12-2015 12:23   org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/ws-addr.xsd
> [opensaml-soap-api-3.1.1.jar] 5574  03-25-2015 14:20   schema/ws-addr.xsd
> {code}
> {code}
>  === ws-policy.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5379 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/ws-policy.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5506  08-25-2015 13:19   schema/wstrust/v1_3/ws-policy.xsd
> [opensaml-soap-api-3.1.1.jar] 5379  03-25-2015 14:20   schema/ws-policy.xsd
> {code}
> {code}
>  === xenc-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 5905 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xenc-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 5293  08-25-2015 13:19   schema/w3c/xmlenc/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5194  07-10-2015 13:51   bindings/schemas/xenc-schema.xsd
> [xmlsec-2.0.5.jar] 5234  07-10-2015 13:51   org/apache/xml/security/resource/schema/xenc-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 5194  07-14-2015 17:09   schemas/xenc-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 5905  03-25-2015 14:19   schema/xenc-schema.xsd
> {code}
> {code}
>  === xmldsig-core-schema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 11283 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmldsig-core-schema.xsd
> [picketlink-federation-2.5.5.CR1.jar] 10659  08-25-2015 13:19   schema/w3c/xmldsig/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10324  07-10-2015 13:51   bindings/schemas/xmldsig-core-schema.xsd
> [xmlsec-2.0.5.jar] 10293  07-10-2015 13:51   org/apache/xml/security/resource/schema/xmldsig-core-schema.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 9927  05-14-2015 15:00   schemas/xmldsig-core-schema.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 10256  07-14-2015 17:09   schemas/xmldsig-core-schema.xsd
> [opensaml-xmlsec-api-3.1.1.jar] 11283  03-25-2015 14:19   schema/xmldsig-core-schema.xsd
> {code}
> {code}
>  === XMLSchema.dtd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 16088 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.dtd
> [jsf-impl-2.2.12-jbossorg-2.jar] 18015  07-29-2015 11:31   com/sun/faces/XMLSchema.dtd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 16085  10-09-2013 15:30   javax/servlet/resources/XMLSchema.dtd
> [picketlink-federation-2.5.5.CR1.jar] 18502  08-25-2015 13:19   schema/w3c/xmlschema/XMLSchema.dtd
> [xmlsec-2.0.5.jar] 16075  07-10-2015 13:51   bindings/schemas/XMLSchema.dtd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 16075  05-14-2015 15:00   schemas/XMLSchema.dtd
> [wss4j-ws-security-stax-2.1.2.jar] 16075  07-14-2015 17:09   schemas/XMLSchema.dtd
> [jbossxacml-2.0.8.Final.jar] 16479  04-04-2012 10:01   schema/xmlschema/XMLSchema.dtd
> [jboss-metadata-common-10.0.0.CR1.jar] 16479  09-16-2015 09:18   dtd/XMLSchema.dtd
> [opensaml-core-3.1.1.jar] 16088  03-25-2015 14:19   schema/XMLSchema.dtd
> {code}
> {code}
>  === XMLSchema.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 100693 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/XMLSchema.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 83892  08-31-2015 16:21   schemas/wsdl/XMLSchema.xsd
> [opensaml-core-3.1.1.jar] 100693  03-25-2015 14:19   schema/XMLSchema.xsd
> {code}
> {code}
>  === xmltooling-config.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2055 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xmltooling-config.xsd
> [opensaml-core-3.1.1.jar] 2055  03-25-2015 14:19   schema/xmltooling-config.xsd
> {code}
> {code}
>  === xml.xsd ===
> -rw-rw-r-- 1 rsvoboda rsvoboda 2870 Sep 17 15:20 /home/rsvoboda/TESTING/700DR10/jboss-eap-7.0/docs/schema/xml.xsd
> [jsf-impl-2.2.12-jbossorg-2.jar] 4925  07-29-2015 11:31   com/sun/faces/xml.xsd
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar] 2922  10-09-2013 15:30   javax/servlet/resources/xml.xsd
> [picketlink-federation-2.5.5.CR1.jar] 4734  08-25-2015 13:19   schema/w3c/xmlschema/xml.xsd
> [xmlsec-2.0.5.jar] 4726  07-10-2015 13:51   bindings/schemas/xml.xsd
> [cxf-core-3.1.2-jbossorg-2.jar] 5840  08-31-2015 16:21   schemas/wsdl/xml.xsd
> [cxf-rt-ws-policy-3.1.2-jbossorg-2.jar] 5829  05-14-2015 15:00   schemas/xml.xsd
> [wss4j-ws-security-stax-2.1.2.jar] 4726  07-14-2015 17:09   schemas/xml.xsd
> [jboss-metadata-common-10.0.0.CR1.jar] 5604  09-16-2015 09:18   schema/xml.xsd
> [opensaml-core-3.1.1.jar] 2870  03-25-2015 14:19   schema/xml.xsd
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:38:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 22 Sep 2015 10:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5385) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675872@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.4365.1442932680106@Atlassian.JIRA>

Heiko Braun created WFLY-5385:
---------------------------------

             Summary: Error executing composite op in domain with two hosts
                 Key: WFLY-5385
                 URL: https://issues.jboss.org/browse/WFLY-5385
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry


{noformat}
 Tue Sep 22 16:35:42 GMT+200 2015
Failed to create security context for host=macbook-pro.fritz.box/server=server-four

Unexpected HTTP response: 500

Request
{
    "operation" => "composite",
    "address" => [],
    "steps" => [{
        "address" => [
            ("host" => "macbook-pro.fritz.box"),
            ("server" => "server-four")
        ],
        "operation" => "read-resource-description",
        "operations" => true,
        "access-control" => "combined-descriptions",
        "include-aliases" => true
    }]
}

Response

Internal Server Error
{
    "outcome" => "failed",
    "result" => {"step-1" => undefined},
    "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
    (\"host\" => \"macbook-pro.fritz.box\"),
    (\"server\" => \"server-four\")
]"}}}}}},
    "rolled-back" => true,
    "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
        "outcome" => "failed",
        "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
    (\"host\" => \"macbook-pro.fritz.box\"),
    (\"server\" => \"server-four\")
]",
        "rolled-back" => true
    }}}}}}
}
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:40:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 22 Sep 2015 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5385) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.4371.1442932800092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111317#comment-13111317 ] 

Heiko Braun commented on WFLY-5385:
-----------------------------------

The host "macbook-pro.fritz.box" is the slave in this setup

> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFLY-5385
>                 URL: https://issues.jboss.org/browse/WFLY-5385
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:41:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 22 Sep 2015 10:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.4375.1442932860178@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun moved WFLY-5385 to WFCORE-998:
------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-998  (was: WFLY-5385)
     Issue Type: Bug  (was: Feature Request)
    Component/s: Domain Management
                     (was: Domain Management)


> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:48:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 10:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-917) Remove setStatusCode call
 in NegotiationMechanism
In-Reply-To: <JIRA.12585671.1442933231000@Atlassian.JIRA>
References: <JIRA.12585671.1442933231000@Atlassian.JIRA>
	<JIRA.12585671.1442933231274@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585671.1442933231000.4385.1442933280155@Atlassian.JIRA>

Darran Lofthouse created SECURITY-917:
-----------------------------------------

             Summary: Remove setStatusCode call in NegotiationMechanism
                 Key: SECURITY-917
                 URL: https://issues.jboss.org/browse/SECURITY-917
             Project: PicketBox 
          Issue Type: Task
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_3_0_0_Final


Once UNDERTOW-548 is resolved we can remove manually setting the status code ourselves.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:55:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 22 Sep 2015 10:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.4399.1442933700335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFCORE-998:
----------------------------------

    Assignee: Heiko Braun  (was: Brian Stansberry)


> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:55:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 22 Sep 2015 10:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.4405.1442933700451@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun closed WFCORE-998.
------------------------------
    Resolution: Rejected


My bad: The server wasn't running (auto-start=false)

> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 10:59:00 2015
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Tue, 22 Sep 2015 10:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-829) Content repo gc task can
 delete content in mid-upload
In-Reply-To: <JIRA.12578450.1437142209000@Atlassian.JIRA>
References: <JIRA.12578450.1437142209000@Atlassian.JIRA>
	<JIRA.12578450.1437142209000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578450.1437142209000.4417.1442933940111@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111328#comment-13111328 ] 

Ingo Weiss commented on WFCORE-829:
-----------------------------------

I am testing on my laptop and using this WAR: {{http://stever.fab.redhat.com:8000/jboss-mail.war}}. You can use it as well.
{noformat}
? 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)
{noformat}

> Content repo gc task can delete content in mid-upload
> -----------------------------------------------------
>
>                 Key: WFCORE-829
>                 URL: https://issues.jboss.org/browse/WFCORE-829
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha10
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>
> Description of problem:
> if upload of an application takes more than 5 minutes, it is removed from repository by clean-obsolete-content.
> - start the upload
> [Host Controller] 15:44:05,456 INFO  [org.jboss.as.repository] (HttpManagementService-threads - 1) JBAS014900: Content added at location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> - After 5 minutes, the content is removed:
> [Host Controller] 15:49:32,111 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014903: Content /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64 is obsolete and will be removed
> [Host Controller] 15:49:32,113 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014901: Content removed from location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> The reference for the deployment is added to domain.xml only after the upload is finished. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 22 11:04:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 11:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5381) Fix pom.xml jpda profile and
 add ability to specify additional surefire forked JVM args via command line
In-Reply-To: <JIRA.12585645.1442922795000@Atlassian.JIRA>
References: <JIRA.12585645.1442922795000@Atlassian.JIRA>
	<JIRA.12585645.1442922795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585645.1442922795000.4424.1442934240301@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111330#comment-13111330 ] 

RH Bugzilla Integration commented on WFLY-5381:
-----------------------------------------------

Dominik Pospisil <dpospisi at redhat.com> changed the Status of [bug 1265229|https://bugzilla.redhat.com/show_bug.cgi?id=1265229] from NEW to POST

> Fix pom.xml jpda profile and add ability to specify additional surefire forked JVM args via command line
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5381
>                 URL: https://issues.jboss.org/browse/WFLY-5381
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.0.0.CR1
>            Reporter: Dominik Pospisil
>            Assignee: Dominik Pospisil
>
> mvn install -Pjpda should run the tests with debugging enabled but it does not as the surefire.jpda.args property is ignored.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:15:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 11:15:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-926) Missing synchronization in
 PackageClassLoader causes a LinkageError: duplicate class definition
In-Reply-To: <JIRA.12585639.1442920477000@Atlassian.JIRA>
References: <JIRA.12585639.1442920477000@Atlassian.JIRA>
	<JIRA.12585639.1442920477000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585639.1442920477000.4442.1442934900087@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-926.
--------------------------------
    Fix Version/s: 7.0.0.Final
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/291ecaba9

> Missing synchronization in PackageClassLoader causes a LinkageError: duplicate class definition
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-926
>                 URL: https://issues.jboss.org/browse/DROOLS-926
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Final
>
>
> Creating multiple KieSessions from a KieBase with a function and using them concurrently from different threads may lead to the following error
> java.util.concurrent.ExecutionException: java.lang.LinkageError: loader (instance of  org/drools/core/rule/JavaDialectRuntimeData$PackageClassLoader): attempted  duplicate class definition for name: "defaultpkg/IsEven"
> 	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> 	at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> 	at org.drools.compiler.integrationtests.Misc2Test.testFunctionInvokingFunction(Misc2Test.java:8191)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
> 	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
> 	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: java.lang.LinkageError: loader (instance of  org/drools/core/rule/JavaDialectRuntimeData$PackageClassLoader): attempted  duplicate class definition for name: "defaultpkg/IsEven"
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> 	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:673)
> 	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:639)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> 	at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> 	at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:214)
> 	at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:254)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:238)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:204)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> 	at org.drools.compiler.integrationtests.Misc2Test$11.call(Misc2Test.java:8180)
> 	at org.drools.compiler.integrationtests.Misc2Test$11.call(Misc2Test.java:8170)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:16:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 11:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-829) Content repo gc task can
 delete content in mid-upload
In-Reply-To: <JIRA.12578450.1437142209000@Atlassian.JIRA>
References: <JIRA.12578450.1437142209000@Atlassian.JIRA>
	<JIRA.12578450.1437142209000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578450.1437142209000.4446.1442934960110@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111334#comment-13111334 ] 

Brian Stansberry commented on WFCORE-829:
-----------------------------------------

I'm not sure how successfully running :upload-deployment-url and then seeing the content deleted 8 mins later is a reproduction of this issue, other than the fact that the deletion was in 8 mins instead of 10. Those missing 2 mins may be a clue to something though!

But you shouldn't expect content to not be gc'd if all you do is run :upload-deployment-url. All that does is put some bits on the server FS, where they are then eligible for gc if no change is made to the persistent config to reference them (i.e. a /deployment=foo:add op).

> Content repo gc task can delete content in mid-upload
> -----------------------------------------------------
>
>                 Key: WFCORE-829
>                 URL: https://issues.jboss.org/browse/WFCORE-829
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha10
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>
> Description of problem:
> if upload of an application takes more than 5 minutes, it is removed from repository by clean-obsolete-content.
> - start the upload
> [Host Controller] 15:44:05,456 INFO  [org.jboss.as.repository] (HttpManagementService-threads - 1) JBAS014900: Content added at location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> - After 5 minutes, the content is removed:
> [Host Controller] 15:49:32,111 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014903: Content /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64 is obsolete and will be removed
> [Host Controller] 15:49:32,113 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014901: Content removed from location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> The reference for the deployment is added to domain.xml only after the upload is finished. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:22:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 11:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.4486.1442935321241@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-756:
------------------------------------
    Fix Version/s: 2.0.0.CR4
                       (was: 2.0.0.CR3)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR4
>
>         Attachments: server.log, server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:22:01 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 11:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-890) Thread deadlock issue in
 class ProjectClassLoader.java
In-Reply-To: <JIRA.12582248.1440242706000@Atlassian.JIRA>
References: <JIRA.12582248.1440242706000@Atlassian.JIRA>
	<JIRA.12582248.1440242706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582248.1440242706000.4490.1442935321430@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-890.
--------------------------------
    Resolution: Done


Trying to reproduce this deadlock I developed this test case https://github.com/droolsjbpm/drools/commit/291ecaba9#diff-70b2034aaa4bb66786671b127de07f80R8144

I have actually reproduced a different problem that I have reported here https://issues.jboss.org/browse/DROOLS-926 and already fixed. 

However using that test case (and a few other variants) I've never been able to reproduce the deadlock reported here. Please reopen this ticket only in case you're able to provide a reproducer.

> Thread deadlock issue in class ProjectClassLoader.java 
> -------------------------------------------------------
>
>                 Key: DROOLS-890
>                 URL: https://issues.jboss.org/browse/DROOLS-890
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.1.0.Final
>            Reporter: Vivek Hingorani
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> In our project , we are using drools6.1.0.Final jars and the rules are deployed in a jar. Another application when trying to use the rules jar is getting thread deadlock problem. Stack trace is 
> at org.drools.core.common.ProjectClassLoader$InternalTypesClassLoader.loadClass(ProjectClassLoader,java284)
> Two threads are in deadlock condition on this thread. I restarted the application and the error is gone but we need to fix this issue so that it is not reproduced later.The class is in drools-core jar



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:23:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5348) Propagate transaction timeout
 value for distributed transaction when using JTA and EJB remoting
In-Reply-To: <JIRA.12585006.1442341335000@Atlassian.JIRA>
References: <JIRA.12585006.1442341335000@Atlassian.JIRA>
	<JIRA.12585006.1442341335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585006.1442341335000.4509.1442935380426@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-5348:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1265300


> Propagate transaction timeout value for distributed transaction when using JTA and EJB remoting
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5348
>                 URL: https://issues.jboss.org/browse/WFLY-5348
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Stephen Fikes
>              Labels: ejb3, jta, transactions
>
> When a transaction begins in "server 1" and an EJB remoting request is made to "server 2" the timeout value for the transaction branch in "server 2" is initially set to {{Integer.MAX_VALUE}} which means {{set-tx-query-timeout}} does not work properly on datasources enlisted in the distributed branch of the transaction in server 2. This essentially requests that statement execution not be timed out at all (though in some cases the large value seems to result in abnormally fast timeout after a couple of seconds).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:27:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 22 Sep 2015 11:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.4567.1442935620301@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFCORE-994:
---------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR4
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:32:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 11:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-916) Add an async servlet to
	the toolkit
In-Reply-To: <JIRA.12585572.1442856490000@Atlassian.JIRA>
References: <JIRA.12585572.1442856490000@Atlassian.JIRA>
	<JIRA.12585572.1442856490000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585572.1442856490000.4603.1442935920619@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-916.
---------------------------------------
    Resolution: Done


> Add an async servlet to the toolkit
> -----------------------------------
>
>                 Key: SECURITY-916
>                 URL: https://issues.jboss.org/browse/SECURITY-916
>             Project: PicketBox 
>          Issue Type: Sub-task
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_CR1
>
>
> The purpose of this is to verify we are delegating in the async case as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:32:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 11:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-910) Add an Undertow SPNEGO
 authentication mechanism
In-Reply-To: <JIRA.12584412.1441807528000@Atlassian.JIRA>
References: <JIRA.12584412.1441807528000@Atlassian.JIRA>
	<JIRA.12584412.1441807528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584412.1441807528000.4606.1442935920679@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-910.
---------------------------------------
    Resolution: Done


> Add an Undertow SPNEGO authentication mechanism
> -----------------------------------------------
>
>                 Key: SECURITY-910
>                 URL: https://issues.jboss.org/browse/SECURITY-910
>             Project: PicketBox 
>          Issue Type: Feature Request
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_CR1
>
>
> Undertow does contain an SPNEGO authentication mechanism however this is not compatible with the LoginModule approach of JBoss Negotiation so an alternative mechanism is required here.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:32:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 11:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-916) Add an async servlet to
	the toolkit
In-Reply-To: <JIRA.12585572.1442856490000@Atlassian.JIRA>
References: <JIRA.12585572.1442856490000@Atlassian.JIRA>
	<JIRA.12585572.1442856490000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585572.1442856490000.4600.1442935920540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-916:
--------------------------------------
    Fix Version/s: Negotiation_3_0_0_CR1
                       (was: Negotiation_3_0_0_Final)


> Add an async servlet to the toolkit
> -----------------------------------
>
>                 Key: SECURITY-916
>                 URL: https://issues.jboss.org/browse/SECURITY-916
>             Project: PicketBox 
>          Issue Type: Sub-task
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_CR1
>
>
> The purpose of this is to verify we are delegating in the async case as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:33:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 11:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-918) Release JBoss Negotiation
	3.0.0.CR1
In-Reply-To: <JIRA.12585679.1442935961000@Atlassian.JIRA>
References: <JIRA.12585679.1442935961000@Atlassian.JIRA>
	<JIRA.12585679.1442935961539@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585679.1442935961000.4616.1442935980559@Atlassian.JIRA>

Darran Lofthouse created SECURITY-918:
-----------------------------------------

             Summary: Release JBoss Negotiation 3.0.0.CR1
                 Key: SECURITY-918
                 URL: https://issues.jboss.org/browse/SECURITY-918
             Project: PicketBox 
          Issue Type: Release
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_3_0_0_CR1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:46:01 2015
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 22 Sep 2015 11:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-248) Constant pool index 268 is
	invalid
In-Reply-To: <JIRA.12577796.1436778937000@Atlassian.JIRA>
References: <JIRA.12577796.1436778937000@Atlassian.JIRA>
	<JIRA.12577796.1436778937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577796.1436778937000.4686.1442936761133@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111350#comment-13111350 ] 

Shigeru Chiba commented on JASSIST-248:
---------------------------------------

Laurent, the problem is because the stub class calls a default method declared in an interface type as if it is an abstract method in that interface.  What generated this stub class?  The generator must be fixed.  If it largely depends on Javassist for the stub generation, I'm happy to fix it.

> Constant pool index 268 is invalid
> ----------------------------------
>
>                 Key: JASSIST-248
>                 URL: https://issues.jboss.org/browse/JASSIST-248
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.19.0-GA
>            Reporter: Laurent Pellegrino
>            Assignee: Shigeru Chiba
>              Labels: regression
>         Attachments: _StubLinkedList.class
>
>
> We are using Javassist for one of our open source projects since about 10 years. Recently, I have tried to upgrade to version 3.19 and 3.20. Unfortunately, with both versions, generated byte code seems to cause errors with the JVM.
> Below is the output:
> {code}
> Exception in thread "RestartDownNodesPolicy node status check" java.lang.VerifyError: Illegal type at constant pool entry 268 in class pa.stub.java.util._StubLinkedList
> Exception Details:
>   Location:
>     pa/stub/java/util/_StubLinkedList.replaceAll(Ljava/util/function/UnaryOperator;)V @43: invokespecial
>   Reason:
>     Constant pool index 268 is invalid
>   Bytecode:
>     0x0000000: 2ab4 00cc 9900 252a b400 0db2 002c 100b
>     0x0000010: 32c0 0028 04bd 00ce 5903 2b53 b200 26b8
>     0x0000020: 00d7 b900 dd02 0057 b12a 2bb7 010c b1  
>   Stackmap Table:
>     same_frame(@41)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:264)
> 	at org.objectweb.proactive.core.mop.MOP.forName(MOP.java:155)
> 	at org.objectweb.proactive.core.mop.MOP.findStubConstructor(MOP.java:649)
> 	at org.objectweb.proactive.core.mop.MOP.createStubObject(MOP.java:822)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:338)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:196)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reifyAsAsynchronous(AbstractBodyProxy.java:277)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.invokeOnBody(AbstractBodyProxy.java:154)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reify(AbstractBodyProxy.java:123)
> 	at pa.stub.org.ow2.proactive.resourcemanager.nodesource._StubNodeSource.getDownNodes(_StubNodeSource.java)
> 	at org.ow2.proactive.resourcemanager.nodesource.policy.RestartDownNodesPolicy$1.run(RestartDownNodesPolicy.java:92)
> 	at java.util.TimerThread.mainLoop(Timer.java:555)
> 	at java.util.TimerThread.run(Timer.java:505)
> {code}
> The issue seems related to default methods introduced in Java 8. Perhaps its not an issue with Javassist but to be honest I don't understand the exception.  However, I have noticed that using Javassist in version 3.18.2 solves the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 11:54:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 11:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-999) Deprecate the
 "upload-deployment-*" ops and add upload-content-*" equivalents
In-Reply-To: <JIRA.12585685.1442937203000@Atlassian.JIRA>
References: <JIRA.12585685.1442937203000@Atlassian.JIRA>
	<JIRA.12585685.1442937203575@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585685.1442937203000.4730.1442937240309@Atlassian.JIRA>

Brian Stansberry created WFCORE-999:
---------------------------------------

             Summary: Deprecate the "upload-deployment-*" ops and add upload-content-*" equivalents
                 Key: WFCORE-999
                 URL: https://issues.jboss.org/browse/WFCORE-999
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Priority: Minor


The upload-deployment-* ops are poorly named, as they support uploading any sort of content, not just deployments. And they also foster the illusion that simply invoking those ops in some way creates a deployment.

The existing ops should be deprecated and the new names created. The same handler classes can be used; this is just a matter of the OperationDefinition that produces the metatdata.

The text description of the new ops should be tweaked a bit as well, to remove any use of the term 'deployment'.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:01:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 12:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-922) Drools Loops with this CEP
	test
In-Reply-To: <JIRA.12585302.1442523468000@Atlassian.JIRA>
References: <JIRA.12585302.1442523468000@Atlassian.JIRA>
	<JIRA.12585302.1442523468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585302.1442523468000.4750.1442937660269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-922:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)


> Drools Loops with this CEP test
> -------------------------------
>
>                 Key: DROOLS-922
>                 URL: https://issues.jboss.org/browse/DROOLS-922
>             Project: Drools
>          Issue Type: Bug
>            Reporter: David Weir
>            Assignee: Mario Fusco
>         Attachments: DroolsLoopingTest.java, MyMessage.java
>
>
> I want to emulate the workflow style rules using state guards. When I run the attached, it loops many times until the incoming event expires.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:01:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 12:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-921) Drools fires no rules with
 this Drools/CEP test
In-Reply-To: <JIRA.12585301.1442523320000@Atlassian.JIRA>
References: <JIRA.12585301.1442523320000@Atlassian.JIRA>
	<JIRA.12585301.1442523320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585301.1442523320000.4754.1442937660354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-921:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)


> Drools fires no rules with this Drools/CEP test
> -----------------------------------------------
>
>                 Key: DROOLS-921
>                 URL: https://issues.jboss.org/browse/DROOLS-921
>             Project: Drools
>          Issue Type: Bug
>            Reporter: David Weir
>            Assignee: Mario Fusco
>         Attachments: DroolsLoopingTest.java, MyMessage.java
>
>
> I'm debugging a looping test and when I run the attached, it fires no rules



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:01:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 12:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-920) DRL compiler throws NPE if
 you import a class from default package
In-Reply-To: <JIRA.12585300.1442523158000@Atlassian.JIRA>
References: <JIRA.12585300.1442523158000@Atlassian.JIRA>
	<JIRA.12585300.1442523158000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585300.1442523158000.4759.1442937660440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-920:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)


> DRL compiler throws NPE if you import a class from default package
> ------------------------------------------------------------------
>
>                 Key: DROOLS-920
>                 URL: https://issues.jboss.org/browse/DROOLS-920
>             Project: Drools
>          Issue Type: Bug
>            Reporter: David Weir
>            Assignee: Mario Fusco
>         Attachments: DroolsLoopingTest.java, MyMessage.java
>
>
> I am working on a looping problem and built the attached test case. It gives me this error when I run it:
> Running DroolsLoopingTest
> Creating new session 
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.compiler.builder.impl.ClassHierarchyManager.inheritFields(ClassHierarchyManager.java:164)
> 	at org.drools.compiler.builder.impl.TypeDeclarationBuilder.createBean(TypeDeclarationBuilder.java:214)
> 	at org.drools.compiler.builder.impl.TypeDeclarationBuilder.processTypeDeclarations(TypeDeclarationBuilder.java:128)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildTypeDeclarations(CompositeKnowledgeBuilderImpl.java:274)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:116)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:104)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:238)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:64)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:225)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:196)
> 	at DroolsLoopingTest.createInMemoryKieSystem(DroolsLoopingTest.java:146)
> 	at DroolsLoopingTest.runTest(DroolsLoopingTest.java:106)
> 	at DroolsLoopingTest.main(DroolsLoopingTest.java:40)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:02:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 12:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-999) Deprecate the
 "upload-deployment-*" ops and *perhaps* add upload-content-*" equivalents
In-Reply-To: <JIRA.12585685.1442937203000@Atlassian.JIRA>
References: <JIRA.12585685.1442937203000@Atlassian.JIRA>
	<JIRA.12585685.1442937203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585685.1442937203000.4760.1442937720054@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-999:
------------------------------------
    Description: 
The upload-deployment-* ops are poorly named, as they support uploading any sort of content, not just deployments. And they also foster the illusion that simply invoking those ops in some way creates a deployment.

The existing ops should be deprecated. 

Beyond that we should *consider* adding equivalent ops named upload-content-*. The same handler classes can be used; this is just a matter of the OperationDefinition that produces the metatdata. The text description of the new ops should be tweaked a bit as well, to remove any use of the term 'deployment'.

*However* it is not certain that we should add these new ops. We should only do it if we have real uses cases that require a separate upload op followed by a persistent config change op. In general config change ops that use bits in the content repo should support directly uploading that content as part of the op, via an attachment stream.

  was:
The upload-deployment-* ops are poorly named, as they support uploading any sort of content, not just deployments. And they also foster the illusion that simply invoking those ops in some way creates a deployment.

The existing ops should be deprecated and the new names created. The same handler classes can be used; this is just a matter of the OperationDefinition that produces the metatdata.

The text description of the new ops should be tweaked a bit as well, to remove any use of the term 'deployment'.

        Summary: Deprecate the "upload-deployment-*" ops and *perhaps* add upload-content-*" equivalents  (was: Deprecate the "upload-deployment-*" ops and add upload-content-*" equivalents)


> Deprecate the "upload-deployment-*" ops and *perhaps* add upload-content-*" equivalents
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-999
>                 URL: https://issues.jboss.org/browse/WFCORE-999
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>
> The upload-deployment-* ops are poorly named, as they support uploading any sort of content, not just deployments. And they also foster the illusion that simply invoking those ops in some way creates a deployment.
> The existing ops should be deprecated. 
> Beyond that we should *consider* adding equivalent ops named upload-content-*. The same handler classes can be used; this is just a matter of the OperationDefinition that produces the metatdata. The text description of the new ops should be tweaked a bit as well, to remove any use of the term 'deployment'.
> *However* it is not certain that we should add these new ops. We should only do it if we have real uses cases that require a separate upload op followed by a persistent config change op. In general config change ops that use bits in the content repo should support directly uploading that content as part of the op, via an attachment stream.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:03:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 12:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-906) Kiescanner do not find
 updates in the KieContainer if the current RELEASE of a maven artifact
 change selecting an older version
In-Reply-To: <JIRA.12584204.1441700444000@Atlassian.JIRA>
References: <JIRA.12584204.1441700444000@Atlassian.JIRA>
	<JIRA.12584204.1441700444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584204.1441700444000.4765.1442937780140@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-906:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)


> Kiescanner do not find updates in the KieContainer if the current RELEASE of a maven artifact change selecting an older version
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-906
>                 URL: https://issues.jboss.org/browse/DROOLS-906
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>         Environment: Ear containing a startup bean, with the kiescanner loaded at postconstruct,
> deployed in Wildfly 8.2.0 
>            Reporter: Getano Piazzolla
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: drools, kie, maven
>
> When using the KieScanner as indicated in the guide, if the kContainer is initalized using a ReleaseIdImpl that idicate
> as version "RELEASE", the KieScanner do not find changes in the repository if we indicate as RELEASE a previous version of the repository.
> IN CODE:
> ReleaseIdImpl releaseId = new ReleaseIdImpl("blabla", "blabla", "RELEASE");
> KieServices ks = KieServices.Factory.get();
> kContainer = ks.newKieContainer(releaseId);
> kieScanner = ks.newKieScanner(kContainer);
> kieScanner.start(5000L);
> For example if we change the maven-metadata.xml/maven-metadata-local.xml 
> FROM
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.2</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> TO
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.1</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> The kieScanner do not find changes; I have to restart the AS to be able to load the correct RELEASE version.
> (The kieScanner behaves and updates correctly if I change the release version from 0.1 to 0.2 )



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:05:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 12:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-999) Deprecate the
 "upload-deployment-*" ops and *perhaps* add upload-content-*" equivalents
In-Reply-To: <JIRA.12585685.1442937203000@Atlassian.JIRA>
References: <JIRA.12585685.1442937203000@Atlassian.JIRA>
	<JIRA.12585685.1442937203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585685.1442937203000.4768.1442937900271@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-999:
------------------------------------
    Description: 
The upload-deployment-* ops are poorly named, as they support uploading any sort of content, not just deployments. And they also foster the illusion that simply invoking those ops in some way creates a deployment.

The existing ops should be deprecated. 

Beyond that we should *consider* adding equivalent ops named upload-content-*. The same handler classes can be used; this is just a matter of the OperationDefinition that produces the metatdata. The text description of the new ops should be tweaked a bit as well, to remove any use of the term 'deployment'.

*However* it is not certain that we should add these new ops. We should only do it if we have real uses cases that require a separate upload op followed by a persistent config change op. In general config change ops that use bits in the content repo should support directly uploading that content as part of the op, via an attachment stream.

The current use cases for the content repo are deployments, deployment-overlays and management-client-content. Patches could in theory use it but at the moment do not.

  was:
The upload-deployment-* ops are poorly named, as they support uploading any sort of content, not just deployments. And they also foster the illusion that simply invoking those ops in some way creates a deployment.

The existing ops should be deprecated. 

Beyond that we should *consider* adding equivalent ops named upload-content-*. The same handler classes can be used; this is just a matter of the OperationDefinition that produces the metatdata. The text description of the new ops should be tweaked a bit as well, to remove any use of the term 'deployment'.

*However* it is not certain that we should add these new ops. We should only do it if we have real uses cases that require a separate upload op followed by a persistent config change op. In general config change ops that use bits in the content repo should support directly uploading that content as part of the op, via an attachment stream.



> Deprecate the "upload-deployment-*" ops and *perhaps* add upload-content-*" equivalents
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-999
>                 URL: https://issues.jboss.org/browse/WFCORE-999
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>
> The upload-deployment-* ops are poorly named, as they support uploading any sort of content, not just deployments. And they also foster the illusion that simply invoking those ops in some way creates a deployment.
> The existing ops should be deprecated. 
> Beyond that we should *consider* adding equivalent ops named upload-content-*. The same handler classes can be used; this is just a matter of the OperationDefinition that produces the metatdata. The text description of the new ops should be tweaked a bit as well, to remove any use of the term 'deployment'.
> *However* it is not certain that we should add these new ops. We should only do it if we have real uses cases that require a separate upload op followed by a persistent config change op. In general config change ops that use bits in the content repo should support directly uploading that content as part of the op, via an attachment stream.
> The current use cases for the content repo are deployments, deployment-overlays and management-client-content. Patches could in theory use it but at the moment do not.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:05:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-918) Release JBoss Negotiation
	3.0.0.CR1
In-Reply-To: <JIRA.12585679.1442935961000@Atlassian.JIRA>
References: <JIRA.12585679.1442935961000@Atlassian.JIRA>
	<JIRA.12585679.1442935961000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585679.1442935961000.4771.1442937900347@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-918.
---------------------------------------
    Resolution: Done


> Release JBoss Negotiation 3.0.0.CR1
> -----------------------------------
>
>                 Key: SECURITY-918
>                 URL: https://issues.jboss.org/browse/SECURITY-918
>             Project: PicketBox 
>          Issue Type: Release
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_CR1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:07:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-915) Migrate MessageFactory
 discovery to use ServiceLoader
In-Reply-To: <JIRA.12585365.1442574176000@Atlassian.JIRA>
References: <JIRA.12585365.1442574176000@Atlassian.JIRA>
	<JIRA.12585365.1442574176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585365.1442574176000.4778.1442938020273@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-915:
--------------------------------------
    Fix Version/s: Negotiation_3_0_0_Final
                       (was: Negotiation_3_0_0_CR1)


> Migrate MessageFactory discovery to use ServiceLoader
> -----------------------------------------------------
>
>                 Key: SECURITY-915
>                 URL: https://issues.jboss.org/browse/SECURITY-915
>             Project: PicketBox 
>          Issue Type: Feature Request
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_Final
>
>
> At the moment we have statically defined class names and attempt to load them in turn to identify which ones are actually available - ServiceLoader based discovery would eliminate this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:14:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2553) Support for SPNEGO
 authentication for deployed web applications
In-Reply-To: <JIRA.12525945.1385146404000@Atlassian.JIRA>
References: <JIRA.12525945.1385146404000@Atlassian.JIRA>
	<JIRA.12525945.1385146404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525945.1385146404000.4842.1442938441296@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111362#comment-13111362 ] 

Darran Lofthouse commented on WFLY-2553:
----------------------------------------

Predominantly the Undertow integration with JBoss Negotiation is compatible with the previous JBoss Web integration the main differences being: -

Undertow does not make use of valves so no valve definition is required within the 'jboss-web.xml' deployment descriptor.

The auth method should be specified as follows in the web.xml: -


{noformat}
	<login-config>
		<auth-method>SPNEGO,FORM</auth-method>
		<realm-name>SPNEGO</realm-name>
		<form-login-config>
			<form-login-page>/login.jsp</form-login-page>
			<form-error-page>/error.jsp</form-error-page>
		</form-login-config>		
	</login-config>
{noformat}

This example is for SPNEGO based authentication with fallback to FORM authentication.

The security domain configuration remains the same as in previous releases.


> Support for SPNEGO authentication for deployed web applications
> ---------------------------------------------------------------
>
>                 Key: WFLY-2553
>                 URL: https://issues.jboss.org/browse/WFLY-2553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:16:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4582) Use Elytron for Java EE
	security
In-Reply-To: <JIRA.12570632.1430755042000@Atlassian.JIRA>
References: <JIRA.12570632.1430755042000@Atlassian.JIRA>
	<JIRA.12570632.1430755042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570632.1430755042000.4856.1442938561060@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-4582:
--------------------------------------

    Assignee: Darran Lofthouse


> Use Elytron for Java EE security
> --------------------------------
>
>                 Key: WFLY-4582
>                 URL: https://issues.jboss.org/browse/WFLY-4582
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> Master issue for converting WildFly's Java EE layer to use Elytron for all security functions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:16:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4582) Use Elytron for Java EE
	security
In-Reply-To: <JIRA.12570632.1430755042000@Atlassian.JIRA>
References: <JIRA.12570632.1430755042000@Atlassian.JIRA>
	<JIRA.12570632.1430755042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570632.1430755042000.4872.1442938561490@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-4582:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1
                       (was: 10.0.0.CR2)


> Use Elytron for Java EE security
> --------------------------------
>
>                 Key: WFLY-4582
>                 URL: https://issues.jboss.org/browse/WFLY-4582
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> Master issue for converting WildFly's Java EE layer to use Elytron for all security functions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:17:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5316) Duplicate auth directories in
	Wildfly 10
In-Reply-To: <JIRA.12584467.1441825072000@Atlassian.JIRA>
References: <JIRA.12584467.1441825072000@Atlassian.JIRA>
	<JIRA.12584467.1441825072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584467.1441825072000.4893.1442938620697@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-5316.
------------------------------------
    Resolution: Rejected


The auth directory is expected to be in the tmp directory of the mode the server is running in - so to auth directories is correct.

> Duplicate auth directories in Wildfly 10
> ----------------------------------------
>
>                 Key: WFLY-5316
>                 URL: https://issues.jboss.org/browse/WFLY-5316
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System, Security
>            Reporter: Fernando Nasser
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> The Wildfly 10 build creates two "auth" directories, one under each config:
> WILDFLY_HOME/domain/tmp: auth
> WILDFLY_HOME/standalone/tmp: auth
> while in Wildfly 8 there was a single "auth" dir at top-level:
> WILDFLY_HOME/auth
> Apparently there is no changes to the code changing where the 'auth' directory is looked for so this may be an issue with the new build system (or was an issue with the old one, but that is not documented).  And as the code creates it if it does not exist this may have been unnoticed in either case.
> We need to get this sorted out asap so we make sure these directories (or directory) are (or is) created with the right permissions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:20:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-414) Add a non-caching
	authentication cache
In-Reply-To: <JIRA.12455369.1324483914000@Atlassian.JIRA>
References: <JIRA.12455369.1324483914000@Atlassian.JIRA>
	<JIRA.12455369.1324483914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455369.1324483914000.4939.1442938800957@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-414:
-------------------------------------

    Assignee: Darran Lofthouse  (was: Anil Saldhana)


> Add a non-caching authentication cache
> --------------------------------------
>
>                 Key: WFLY-414
>                 URL: https://issues.jboss.org/browse/WFLY-414
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> Add an option to either disable the authentication cache or a cache implementation that does not cache.
> This is for incoming requests where we do not have a username and password available to use to retrieve an verify items from a cache.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:20:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Sep 2015 12:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-414) Add a non-caching
	authentication cache
In-Reply-To: <JIRA.12455369.1324483914000@Atlassian.JIRA>
References: <JIRA.12455369.1324483914000@Atlassian.JIRA>
	<JIRA.12455369.1324483914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455369.1324483914000.4943.1442938801049@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-414:
----------------------------------
    Fix Version/s:     (was: 10.0.0.CR2)


> Add a non-caching authentication cache
> --------------------------------------
>
>                 Key: WFLY-414
>                 URL: https://issues.jboss.org/browse/WFLY-414
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> Add an option to either disable the authentication cache or a cache implementation that does not cache.
> This is for incoming requests where we do not have a username and password available to use to retrieve an verify items from a cache.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:27:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Sep 2015 12:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-920) DRL compiler throws NPE if
 you import a class from default package
In-Reply-To: <JIRA.12585300.1442523158000@Atlassian.JIRA>
References: <JIRA.12585300.1442523158000@Atlassian.JIRA>
	<JIRA.12585300.1442523158000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585300.1442523158000.4968.1442939220205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-920.
--------------------------------
    Resolution: Rejected


This is not a Drools bug but a well known Java limitation. From the Java language spec:

"It is a compile time error to import a type from the unnamed package."

See http://stackoverflow.com/questions/2193226/how-to-import-a-class-from-default-package


> DRL compiler throws NPE if you import a class from default package
> ------------------------------------------------------------------
>
>                 Key: DROOLS-920
>                 URL: https://issues.jboss.org/browse/DROOLS-920
>             Project: Drools
>          Issue Type: Bug
>            Reporter: David Weir
>            Assignee: Mario Fusco
>         Attachments: DroolsLoopingTest.java, MyMessage.java
>
>
> I am working on a looping problem and built the attached test case. It gives me this error when I run it:
> Running DroolsLoopingTest
> Creating new session 
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.compiler.builder.impl.ClassHierarchyManager.inheritFields(ClassHierarchyManager.java:164)
> 	at org.drools.compiler.builder.impl.TypeDeclarationBuilder.createBean(TypeDeclarationBuilder.java:214)
> 	at org.drools.compiler.builder.impl.TypeDeclarationBuilder.processTypeDeclarations(TypeDeclarationBuilder.java:128)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildTypeDeclarations(CompositeKnowledgeBuilderImpl.java:274)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:116)
> 	at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:104)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:238)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:64)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:225)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:196)
> 	at DroolsLoopingTest.createInMemoryKieSystem(DroolsLoopingTest.java:146)
> 	at DroolsLoopingTest.runTest(DroolsLoopingTest.java:106)
> 	at DroolsLoopingTest.main(DroolsLoopingTest.java:40)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:53:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Sep 2015 12:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1060) When starting JBoss AS -b
 should work no matter how I start JBoss AS to bind it to the local
 interface
In-Reply-To: <JIRA.12469850.1341334879000@Atlassian.JIRA>
References: <JIRA.12469850.1341334879000@Atlassian.JIRA>
	<JIRA.12469850.1341334879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469850.1341334879000.5018.1442940780277@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111376#comment-13111376 ] 

RH Bugzilla Integration commented on WFLY-1060:
-----------------------------------------------

Andrea Hoffer <ahoffer at redhat.com> changed the Status of [bug 1125025|https://bugzilla.redhat.com/show_bug.cgi?id=1125025] from MODIFIED to ON_QA

> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1060
>                 URL: https://issues.jboss.org/browse/WFLY-1060
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>              Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address.  Instead it binds to localhost 127.0.0.1.  It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:53:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 12:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3605) Move the JMX subsystem out of
	core
In-Reply-To: <JIRA.12545977.1404925999000@Atlassian.JIRA>
References: <JIRA.12545977.1404925999000@Atlassian.JIRA>
	<JIRA.12545977.1404925999000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545977.1404925999000.5023.1442940780567@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-3605.
------------------------------------
    Resolution: Rejected


I don't want to do this. JMX is too tied to management to make the cost worth the benefit.

> Move the JMX subsystem out of core
> ----------------------------------
>
>                 Key: WFLY-3605
>                 URL: https://issues.jboss.org/browse/WFLY-3605
>             Project: WildFly
>          Issue Type: Task
>          Components: JMX
>            Reporter: Darran Lofthouse
>            Assignee: Brian Stansberry
>
> There are some dependency issues to resolve but the JMX subsystem should not automatically be included in the core distribution.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:57:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 12:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-909) Allow tests to turn on
 boot-time enforcement of capability resolution in an --admin-only process
In-Reply-To: <JIRA.12582523.1440504992000@Atlassian.JIRA>
References: <JIRA.12582523.1440504992000@Atlassian.JIRA>
	<JIRA.12582523.1440504992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582523.1440504992000.5026.1442941020239@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-909:
------------------------------------
    Fix Version/s: 3.0.0.Alpha1
                       (was: 2.0.0.CR4)


> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-909
>                 URL: https://issues.jboss.org/browse/WFCORE-909
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 3.0.0.Alpha1
>
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:57:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 12:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5194) Restore the original legacy
 configs for use in ParseAndMarshalModelsTestCase
In-Reply-To: <JIRA.12582395.1440466809000@Atlassian.JIRA>
References: <JIRA.12582395.1440466809000@Atlassian.JIRA>
	<JIRA.12582395.1440466809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582395.1440466809000.5037.1442941020430@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFLY-5194:
---------------------------------------

    Assignee: ehsavoie Hugonnet


> Restore the original legacy configs for use in ParseAndMarshalModelsTestCase
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5194
>                 URL: https://issues.jboss.org/browse/WFLY-5194
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> The configs currently used in ParseAndMarshalModelsTestCase are edited variants, with legacy subsystems no longer supported removed. But that removal should no longer be necessary, since the tests use --admin-only mode and we have committed to support these subsystems in --admin-only. So we should restore the missing bits to have a more accurate test that legacy configs will work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 12:58:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 22 Sep 2015 12:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-987)
 java.lang.StringIndexOutOfBoundsException when empty string is used in a
 resource address value
In-Reply-To: <JIRA.12585297.1442517259000@Atlassian.JIRA>
References: <JIRA.12585297.1442517259000@Atlassian.JIRA>
	<JIRA.12585297.1442517259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585297.1442517259000.5049.1442941080353@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFCORE-987:
----------------------------------------

    Assignee: ehsavoie Hugonnet


> java.lang.StringIndexOutOfBoundsException when empty string is used in a resource address value
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-987
>                 URL: https://issues.jboss.org/browse/WFCORE-987
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11
>         Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20
>            Reporter: Tomas Remes
>            Assignee: ehsavoie Hugonnet
>             Fix For: 3.0.0.Alpha1
>
>
> Following copied from WFCORE-212 shows a StringIndexOutOfBounds being thrown when the empty string is the 'value' passed to PathElement.pathElement(key, value). The point of this JIRA is not to correct the reason for that empty string, but rather to fail cleanly (probably with the same logic used for the value == null case.)
> Following steps to reproduce section you will encounter this exception:
> {noformat}
> 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 	at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20]
> 	at org.jboss.as.controller.PathElement.<init>(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.<init>(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:05:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 13:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-628) Support for 'query'
 operation on legacy slaves
In-Reply-To: <JIRA.12567846.1428430772000@Atlassian.JIRA>
References: <JIRA.12567846.1428430772000@Atlassian.JIRA>
	<JIRA.12567846.1428430772000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567846.1428430772000.5066.1442941500056@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-628:
------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
>                 Key: WFCORE-628
>                 URL: https://issues.jboss.org/browse/WFCORE-628
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:20:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 22 Sep 2015 13:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1000) Take into account cpuset
 masks on Linux when using cpu count for sizing pools
In-Reply-To: <JIRA.12585688.1442942387000@Atlassian.JIRA>
References: <JIRA.12585688.1442942387000@Atlassian.JIRA>
	<JIRA.12585688.1442942387472@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585688.1442942387000.5086.1442942400088@Atlassian.JIRA>

Jason Greene created WFCORE-1000:
------------------------------------

             Summary: Take into account cpuset masks on Linux when using cpu count for sizing pools
                 Key: WFCORE-1000
                 URL: https://issues.jboss.org/browse/WFCORE-1000
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Server
            Reporter: Jason Greene
            Assignee: Jason Greene
             Fix For: 2.0.0.CR4






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:23:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 22 Sep 2015 13:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1000) Take into account cpuset
 masks on Linux when using cpu count for sizing pools
In-Reply-To: <JIRA.12585688.1442942387000@Atlassian.JIRA>
References: <JIRA.12585688.1442942387000@Atlassian.JIRA>
	<JIRA.12585688.1442942387000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585688.1442942387000.5094.1442942580098@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFCORE-1000:
---------------------------------
    Description: On Linux, Runtime.getRuntime().availableProcessors() always returns the host CPU count regardless of the process' cpuset affinity. This effectively means usage of cgroups (e.g. using docker) and numactl will lead to oversized thread pools. While this issue should be fixed in the JVM, we should workaround the problem by reading /proc. 


> Take into account cpuset masks on Linux when using cpu count for sizing pools
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-1000
>                 URL: https://issues.jboss.org/browse/WFCORE-1000
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Server
>            Reporter: Jason Greene
>            Assignee: Jason Greene
>             Fix For: 2.0.0.CR4
>
>
> On Linux, Runtime.getRuntime().availableProcessors() always returns the host CPU count regardless of the process' cpuset affinity. This effectively means usage of cgroups (e.g. using docker) and numactl will lead to oversized thread pools. While this issue should be fixed in the JVM, we should workaround the problem by reading /proc. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:25:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 22 Sep 2015 13:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1000) Take into account cpuset
 affinity on Linux when using cpu count for sizing pools
In-Reply-To: <JIRA.12585688.1442942387000@Atlassian.JIRA>
References: <JIRA.12585688.1442942387000@Atlassian.JIRA>
	<JIRA.12585688.1442942387000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585688.1442942387000.5097.1442942700101@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFCORE-1000:
---------------------------------
    Summary: Take into account cpuset affinity on Linux when using cpu count for sizing pools  (was: Take into account cpuset masks on Linux when using cpu count for sizing pools)


> Take into account cpuset affinity on Linux when using cpu count for sizing pools
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-1000
>                 URL: https://issues.jboss.org/browse/WFCORE-1000
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Server
>            Reporter: Jason Greene
>            Assignee: Jason Greene
>             Fix For: 2.0.0.CR4
>
>
> On Linux, Runtime.getRuntime().availableProcessors() always returns the host CPU count regardless of the process' cpuset affinity. This effectively means usage of cgroups (e.g. using docker) and numactl will lead to oversized thread pools. While this issue should be fixed in the JVM, we should workaround the problem by reading /proc. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:47:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 22 Sep 2015 13:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5386) Starting embedded server
 overwrites standalone/config/logging.properties with a mostly blank config
In-Reply-To: <JIRA.12585689.1442943974000@Atlassian.JIRA>
References: <JIRA.12585689.1442943974000@Atlassian.JIRA>
	<JIRA.12585689.1442943974025@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585689.1442943974000.5107.1442944020069@Atlassian.JIRA>

Ken Wills created WFLY-5386:
-------------------------------

             Summary: Starting embedded server overwrites standalone/config/logging.properties with a mostly blank config
                 Key: WFLY-5386
                 URL: https://issues.jboss.org/browse/WFLY-5386
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Ken Wills
            Assignee: Ken Wills


Note the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties

 $ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server --std-out=echo

Check the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties, the file is empty.

Starting standalone will restore the default contents.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:48:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 22 Sep 2015 13:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1001) Starting embedded server
 overwrites standalone/config/logging.properties with a mostly blank config
In-Reply-To: <JIRA.12585689.1442943974000@Atlassian.JIRA>
References: <JIRA.12585689.1442943974000@Atlassian.JIRA>
	<JIRA.12585689.1442943974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585689.1442943974000.5113.1442944080196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills moved WFLY-5386 to WFCORE-1001:
-----------------------------------------

       Project: WildFly Core  (was: WildFly)
           Key: WFCORE-1001  (was: WFLY-5386)
    Issue Type: Bug  (was: Feature Request)


> Starting embedded server overwrites standalone/config/logging.properties with a mostly blank config
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1001
>                 URL: https://issues.jboss.org/browse/WFCORE-1001
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> Note the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties
>  $ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> Check the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties, the file is empty.
> Starting standalone will restore the default contents.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:50:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 22 Sep 2015 13:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-937) --std-out=discard for
 embedded host controller doesn't work
In-Reply-To: <JIRA.12583210.1441006072000@Atlassian.JIRA>
References: <JIRA.12583210.1441006072000@Atlassian.JIRA>
	<JIRA.12583210.1441006072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583210.1441006072000.5117.1442944200275@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111388#comment-13111388 ] 

James Perkins commented on WFCORE-937:
--------------------------------------

The {{org.jboss.logmanager.console.ConsoleHandler}} initiates a static [{{stdout}} and {{stderr}}|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/java/org/jboss/logmanager/handlers/ConsoleHandler.java#L35-L36] field. Since this class has already been initiated, it's using the "correct"/default `System.out` stream.

In the [{{EmbedHostControllerHandler.configureLogContext()}}|https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org/jboss/as/cli/embedded/EmbedHostControllerHandler.java#L258-L278] we might need to exclude the console handler if `--std-out=discard` was defined. We should do this through the `LogContextConfiguration` API which I can help with if needed.

> --std-out=discard for embedded host controller doesn't work
> -----------------------------------------------------------
>
>                 Key: WFCORE-937
>                 URL: https://issues.jboss.org/browse/WFCORE-937
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR4
>
>
> Embedded host controller always prints the logs to the console no matter which --std-out= value I choose.
> {noformat}
> [disconnected /] embed-host-controller --std-out=discard
> 09:22:06,627 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.3.Final
> 09:22:06,733 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
> 09:22:06,758 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 09:22:07,769 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,799 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,824 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,843 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:08,067 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) (Host Controller) started in 1353ms - Started 25 of 27 services (8 services are lazy, passive or on-demand)
> [domain at embedded /] stop-embedded-host-controller 
> 09:22:15,926 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 5ms
> [disconnected /] exit 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 13:50:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 22 Sep 2015 13:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1001) Starting embedded server
 overwrites standalone/config/logging.properties with a mostly blank config
In-Reply-To: <JIRA.12585689.1442943974000@Atlassian.JIRA>
References: <JIRA.12585689.1442943974000@Atlassian.JIRA>
	<JIRA.12585689.1442943974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585689.1442943974000.5120.1442944200324@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-1001:
------------------------------
    Fix Version/s: 2.0.0.CR4


> Starting embedded server overwrites standalone/config/logging.properties with a mostly blank config
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1001
>                 URL: https://issues.jboss.org/browse/WFCORE-1001
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR4
>
>
> Note the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties
>  $ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> Check the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties, the file is empty.
> Starting standalone will restore the default contents.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 14:14:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 22 Sep 2015 14:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-937) --std-out=discard for
 embedded host controller doesn't work
In-Reply-To: <JIRA.12583210.1441006072000@Atlassian.JIRA>
References: <JIRA.12583210.1441006072000@Atlassian.JIRA>
	<JIRA.12583210.1441006072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583210.1441006072000.5244.1442945640357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFCORE-937:
------------------------------------

    Assignee: James Perkins  (was: Ken Wills)


> --std-out=discard for embedded host controller doesn't work
> -----------------------------------------------------------
>
>                 Key: WFCORE-937
>                 URL: https://issues.jboss.org/browse/WFCORE-937
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: James Perkins
>             Fix For: 2.0.0.CR4
>
>
> Embedded host controller always prints the logs to the console no matter which --std-out= value I choose.
> {noformat}
> [disconnected /] embed-host-controller --std-out=discard
> 09:22:06,627 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.3.Final
> 09:22:06,733 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
> 09:22:06,758 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) starting
> 09:22:07,769 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,799 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,824 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:07,843 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 09:22:08,067 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) (Host Controller) started in 1353ms - Started 25 of 27 services (8 services are lazy, passive or on-demand)
> [domain at embedded /] stop-embedded-host-controller 
> 09:22:15,926 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta4) stopped in 5ms
> [disconnected /] exit 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 15:36:00 2015
From: issues at jboss.org (Dirk Weil (JIRA))
Date: Tue, 22 Sep 2015 15:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5235) CDI interceptors are not
 called when invoking observer method
In-Reply-To: <JIRA.12583196.1440938405000@Atlassian.JIRA>
References: <JIRA.12583196.1440938405000@Atlassian.JIRA>
	<JIRA.12583196.1440938405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583196.1440938405000.5629.1442950560228@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111464#comment-13111464 ] 

Dirk Weil commented on WFLY-5235:
---------------------------------

I finally found some time to dig into the problem a little bit more: If the observer method is private, interceptors are not called. With non-private methods, interceptors are working as expected. This behaviour has changed from WildFly 8.2.0 to 9.0.1. I didn't check WildFly 10.

I tried to find out from the specification, if interceptors should be called when invoking private methods, but found no unmistakable statement. If someone could clarify that, I would be very thankful.

I can imagine, that the methods intercepted must be non-private. But if that is the case, an appropriate exception should be thrown, if they are private.

The problem can be reproduced with this demo: https://github.com/dirkweil/wildfly-cdiscopeinit-demo. If you build the application (just run mvn) and deploy the resulting war file onto WildFly 8, no exception arises. If using WildFly 9 a TransactionRequiredException is thrown in the observer method de.gedoplan.beantrial.wildflycdiscopeinit.service.InitTestDataService.createTestData.

> CDI interceptors are not called when invoking observer method
> -------------------------------------------------------------
>
>                 Key: WFLY-5235
>                 URL: https://issues.jboss.org/browse/WFLY-5235
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 9.0.1.Final
>            Reporter: Dirk Weil
>            Assignee: Martin Kouba
>
> The following code runs with an active transaction on WFLY 8.2.0, but failes with an TransactionRequiredException on WFLY 9.0.1:
> @ApplicationScoped
> public class InitCocktailDemoDataService
> {
>   @PersistenceContext
>   private EntityManager entityManager;
>   @Transactional
>   private void createDemoData(@Observes @Initialized(ApplicationScoped.class) Object event)
>   {
>         this.entityManager.merge(someEntity);
>       }
> It seems that interceptors aren't called at all - at least for observers of scope lifecycle events.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 16:04:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Tue, 22 Sep 2015 16:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.5682.1442952240255@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111472#comment-13111472 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

Could this be related to the bug below.

https://issues.jboss.org/browse/WFLY-4624

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 16:17:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 22 Sep 2015 16:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.5757.1442953020382@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111482#comment-13111482 ] 

Ken Wills commented on WFCORE-993:
----------------------------------

This appears to work for me with:

Embedded HC:

$ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-host-controller --std-out=echo
15:12:21,532 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
15:12:21,690 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
15:12:21,717 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:12:22,252 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" (Host Controller) started in 704ms - Started 25 of 27 services (8 services are lazy, passive or on-demand)
[domain at embedded /] reload --host=master
15:12:27,248 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" stopped in 4ms
15:12:27,248 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:12:27,318 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" (Host Controller) started in 69ms - Started 25 of 27 services (8 services are lazy, passive or on-demand)
[domain at embedded /] 

Standalone:

$ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server --std-out=echo 
15:13:45,685 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
15:13:45,734 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
15:13:45,787 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:13:46,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" started in 538ms - Started 35 of 42 services (13 services are lazy, passive or on-demand)
[standalone at embedded /] reload --admin-only=true 
15:13:55,552 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" stopped in 9ms
15:13:55,554 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:13:55,598 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" started in 42ms - Started 35 of 42 services (13 services are lazy, passive or on-demand)
[standalone at embedded /] reload --admin-only=true
15:13:59,883 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" stopped in 3ms
15:13:59,887 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:13:59,939 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" started in 49ms - Started 35 of 42 services (13 services are lazy, passive or on-demand)
[standalone at embedded /]

test.cli:

$ cat test.cli 
embed-server --std-out=echo
reload --admin-only=false
reload --admin-only=true

$ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh --file=test.cli

15:15:40,753 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
15:15:40,833 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
15:15:40,883 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:15:41,312 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" started in 553ms - Started 35 of 42 services (13 services are lazy, passive or on-demand)
15:15:41,391 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" stopped in 5ms
15:15:41,393 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:15:41,426 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
15:15:41,440 INFO  [org.xnio] (MSC service thread 1-5) XNIO version 3.3.2.Final
15:15:41,452 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.3.2.Final
15:15:41,475 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 4.0.10.Final
15:15:41,495 WARN  [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
15:15:41,555 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
15:15:41,557 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
15:15:41,559 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" started in 157ms - Started 55 of 57 services (15 services are lazy, passive or on-demand)
15:15:41,594 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" stopped in 2ms
15:15:41,596 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" starting
15:15:41,650 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" started in 52ms - Started 35 of 42 services (13 services are lazy, passive or on-demand)
15:15:41,695 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Core 2.0.0.CR4-SNAPSHOT "Kenny" stopped in 1ms


> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 16:17:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 22 Sep 2015 16:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.5760.1442953020452@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills reassigned WFCORE-993:
--------------------------------

    Assignee: Petr Kremensky  (was: Ken Wills)


> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 16:38:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 22 Sep 2015 16:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.5825.1442954280150@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111492#comment-13111492 ] 

Paul Ferraro commented on WFLY-5358:
------------------------------------

[~czacharym] WFLY-4624 is unrelated.

Your configuration uses 2 properties that are deprecated in the JGroups version used in WF10.  The replacement options are described appropriately in the WARN messages: TCPPING.timeout is replaced by GMS.join_timeout and TCPPING.num_initial_members is no longer used and has no replacement.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 17:23:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 17:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1002)
 TransactionalProtocolOperationHandler.AbortOperationHandler must initialize
 the ExecuteRequestContext before responding
In-Reply-To: <JIRA.12585720.1442956922000@Atlassian.JIRA>
References: <JIRA.12585720.1442956922000@Atlassian.JIRA>
	<JIRA.12585720.1442956922821@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585720.1442956922000.5902.1442956980350@Atlassian.JIRA>

Brian Stansberry created WFCORE-1002:
----------------------------------------

             Summary: TransactionalProtocolOperationHandler.AbortOperationHandler must initialize the ExecuteRequestContext before responding
                 Key: WFCORE-1002
                 URL: https://issues.jboss.org/browse/WFCORE-1002
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.CR3
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


If in a race a COMPLETE_TX_REQUEST cancelling an op is processed by a server/slave HC before the original EXECUTE_TX_REQUEST is processed, when the EXECUTE_TX_REQUEST comes in the AbortOperationHandler attempts to respond with a "outcome"=>"cancelled" response. This will fail because the ExecutionRequestContext will not be initialized.

In this situation the AbortOperationHandler should initialize the ERC.

With assertions enabled, this appears in the log:

{code}
20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) Exception in thread "Remoting "slave:main-three:MANAGEMENT" task-6" java.lang.AssertionError

20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:458)

20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$AbortOperationHandler.handleRequest(TransactionalProtocolOperationHandler.java:275)

20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)

20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)

20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)

20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)

20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)

20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)

20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:705)

20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.lang.Thread.run(Thread.java:745)
{code}

Without assertions, a few lines later a call to sendResponse will result in an NPE.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 20:34:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Sep 2015 20:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5325) When Making any JAXRS rest
 call NPE is being thrown in
 org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
In-Reply-To: <JIRA.12584677.1441975568000@Atlassian.JIRA>
References: <JIRA.12584677.1441975568000@Atlassian.JIRA>
	<JIRA.12584677.1441975568000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584677.1441975568000.6084.1442968440222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-5325.
----------------------------------
    Resolution: Rejected


JAXRSBeanValidationInInterceptor is not part of Wildfly, I think you must be bundling CXF in your app which is causing compatibility issues with RESTEasy

> When Making any JAXRS rest call NPE is being thrown in  org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5325
>                 URL: https://issues.jboss.org/browse/WFLY-5325
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Wessel Pieterse
>            Assignee: Jason Greene
>
> The follwing line in my CORSFilter :
> {code:java}
> chain.doFilter(request, response);
> {code}
> causes
> {code:java}
> wildfly_1      | 12:41:34,692 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-8) Unknown exception while executing POST /orders/214/pay/creditcard/payu: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
> wildfly_1      | 
> wildfly_1      | 12:41:34,693 ERROR [com.unijunction.ordercloud.filter.CORSFilter] (default task-8) CORSFilter failed :: javax.servlet.ServletException: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.cleanup(AdviceFilter.java:196)
> wildfly_1      | 	at org.apache.shiro.web.filter.authc.AuthenticatingFilter.cleanup(AuthenticatingFilter.java:155)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:148)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> wildfly_1      | 	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> wildfly_1      | 	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> wildfly_1      | 	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.OrganisationHeaderFilter.doFilter(OrganisationHeaderFilter.java:43)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at com.unijunction.ordercloud.filter.CORSFilter.doFilter(CORSFilter.java:67)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> wildfly_1      | 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> wildfly_1      | 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> wildfly_1      | 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> wildfly_1      | 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> wildfly_1      | 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> wildfly_1      | 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> wildfly_1      | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> wildfly_1      | 	at java.lang.Thread.run(Thread.java:745)
> wildfly_1      | Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> wildfly_1      | 	at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> wildfly_1      | 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> wildfly_1      | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> wildfly_1      | 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> wildfly_1      | 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
> wildfly_1      | 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> wildfly_1      | 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> wildfly_1      | 	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> wildfly_1      | 	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> wildfly_1      | 	... 52 more
> wildfly_1      | Caused by: java.lang.NullPointerException
> wildfly_1      | 	at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:264)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> wildfly_1      | 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
> wildfly_1      | 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> wildfly_1      | 	... 65 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 20:47:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 20:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.6091.1442969220146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-988:
------------------------------------
    Git Pull Request: https://issues.jboss.org/browse/WFCORE-988


> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 20:48:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 20:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-989) Premature registration of
 reconnecting server
In-Reply-To: <JIRA.12585427.1442632267000@Atlassian.JIRA>
References: <JIRA.12585427.1442632267000@Atlassian.JIRA>
	<JIRA.12585427.1442632267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585427.1442632267000.6093.1442969280107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-989:
------------------------------------
    Git Pull Request: https://issues.jboss.org/browse/WFCORE-988


> Premature registration of reconnecting server
> ---------------------------------------------
>
>                 Key: WFCORE-989
>                 URL: https://issues.jboss.org/browse/WFCORE-989
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> ServerInventoryImpl.reconnectServer is registering the ProxyController for the reconnecting server with the DomainModelControllerService. The problem is that ProxyController is not yet in a state where it can forward requests to the server. That won't happen until the server calls back with a DomainServerProtocol.SERVER_RECONNECT_REQUEST and the ServerToHostProtocolHandler.ServerReconnectRequestHandler handles it. The effect is if a request for the server comes in during this window, it will fail. If that request is part of a domain operation rollout (because during the window the HC regarded the server as 'live' and instructed the DC to send rollout ops to it), then the domain rollout will be affected. This happened in the testsuite failure I just saw. Most significant logging is as follows:
> {code}
> 2015-09-18 17:59:32,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" (Host Controller) started in 93ms - Started 48 of 51 services (15 services are lazy, passive or on-demand)
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-16) Initialized for 1849055188
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-14) WFLYHC0021: Server [Server:main-three] connected using connection [Channel ID 08aa200b (inbound) of Remoting connection 27e3d90d to /127.0.0.1:49272]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-15) WFLYHC0021: Server [Server:other-two] connected using connection [Channel ID 02bd2646 (inbound) of Remoting connection 64a8b7f2 to /127.0.0.1:49273]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) Initialized for 1849055188
> 2015-09-18 17:59:32,252 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) sending prepared response for 1849055188  --- interrupted: false
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 481103151
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) Initialized for 481103151
> 2015-09-18 17:59:32,255 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) sending pre-prepare failed response for 1933145457  --- interrupted: false
> 2015-09-18 17:59:32,256 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) sending pre-prepare failed response for 481103151  --- interrupted: false
> {code}
> The HC completes boot. Then servers main-three and other-two register. The HC sends a prepared response to a request. This is the host rollout request to the slave from the DC with the response being the ops to invoke on the servers. The HC reports sending a "pre-prepare failed response" to two requests. These are the requests the DC has asked it to proxy to the servers.
> The result of all this for the client is the following failure of a management op:
> {code}
> Failed operation:
> {
>     "operation" => "add",
>     "address" => [("extension" => "org.jboss.as.test.hc.extension")]
> }
> Response:
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"slave" => {"main-three" => "WFLYHC0153: Channel closed"}}},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => "WFLYHC0153: Channel closed"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {
>             "master" => {"main-one" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => [("HC" => "1.1.1")],
>                 "rolled-back" => true
>             }}},
>             "slave" => {"main-three" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => undefined,
>                 "failure-description" => "WFLYHC0153: Channel closed",
>                 "rolled-back" => true
>             }}}
>         }},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYHC0153: Channel closed",
>             "rolled-back" => true
>         }}}}}
>     }
> }
> {code}
> The "WFLYHC0153: Channel closed" failure is what is produced when an attempt is made to invoke on a disconnected proxy controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 20:49:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 20:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-989) Premature registration of
 reconnecting server
In-Reply-To: <JIRA.12585427.1442632267000@Atlassian.JIRA>
References: <JIRA.12585427.1442632267000@Atlassian.JIRA>
	<JIRA.12585427.1442632267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585427.1442632267000.6097.1442969340132@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-989:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1086  (was: https://issues.jboss.org/browse/WFCORE-988)


> Premature registration of reconnecting server
> ---------------------------------------------
>
>                 Key: WFCORE-989
>                 URL: https://issues.jboss.org/browse/WFCORE-989
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> ServerInventoryImpl.reconnectServer is registering the ProxyController for the reconnecting server with the DomainModelControllerService. The problem is that ProxyController is not yet in a state where it can forward requests to the server. That won't happen until the server calls back with a DomainServerProtocol.SERVER_RECONNECT_REQUEST and the ServerToHostProtocolHandler.ServerReconnectRequestHandler handles it. The effect is if a request for the server comes in during this window, it will fail. If that request is part of a domain operation rollout (because during the window the HC regarded the server as 'live' and instructed the DC to send rollout ops to it), then the domain rollout will be affected. This happened in the testsuite failure I just saw. Most significant logging is as follows:
> {code}
> 2015-09-18 17:59:32,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" (Host Controller) started in 93ms - Started 48 of 51 services (15 services are lazy, passive or on-demand)
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-16) Initialized for 1849055188
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-14) WFLYHC0021: Server [Server:main-three] connected using connection [Channel ID 08aa200b (inbound) of Remoting connection 27e3d90d to /127.0.0.1:49272]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-15) WFLYHC0021: Server [Server:other-two] connected using connection [Channel ID 02bd2646 (inbound) of Remoting connection 64a8b7f2 to /127.0.0.1:49273]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) Initialized for 1849055188
> 2015-09-18 17:59:32,252 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) sending prepared response for 1849055188  --- interrupted: false
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 481103151
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) Initialized for 481103151
> 2015-09-18 17:59:32,255 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) sending pre-prepare failed response for 1933145457  --- interrupted: false
> 2015-09-18 17:59:32,256 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) sending pre-prepare failed response for 481103151  --- interrupted: false
> {code}
> The HC completes boot. Then servers main-three and other-two register. The HC sends a prepared response to a request. This is the host rollout request to the slave from the DC with the response being the ops to invoke on the servers. The HC reports sending a "pre-prepare failed response" to two requests. These are the requests the DC has asked it to proxy to the servers.
> The result of all this for the client is the following failure of a management op:
> {code}
> Failed operation:
> {
>     "operation" => "add",
>     "address" => [("extension" => "org.jboss.as.test.hc.extension")]
> }
> Response:
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"slave" => {"main-three" => "WFLYHC0153: Channel closed"}}},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => "WFLYHC0153: Channel closed"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {
>             "master" => {"main-one" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => [("HC" => "1.1.1")],
>                 "rolled-back" => true
>             }}},
>             "slave" => {"main-three" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => undefined,
>                 "failure-description" => "WFLYHC0153: Channel closed",
>                 "rolled-back" => true
>             }}}
>         }},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYHC0153: Channel closed",
>             "rolled-back" => true
>         }}}}}
>     }
> }
> {code}
> The "WFLYHC0153: Channel closed" failure is what is produced when an attempt is made to invoke on a disconnected proxy controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 20:49:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 20:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.6101.1442969340671@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-988:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1086  (was: https://issues.jboss.org/browse/WFCORE-988)


> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 20:51:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 20:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1002)
 TransactionalProtocolOperationHandler.AbortOperationHandler must initialize
 the ExecuteRequestContext before responding
In-Reply-To: <JIRA.12585720.1442956922000@Atlassian.JIRA>
References: <JIRA.12585720.1442956922000@Atlassian.JIRA>
	<JIRA.12585720.1442956922000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585720.1442956922000.6103.1442969460220@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1002:
-------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1086


> TransactionalProtocolOperationHandler.AbortOperationHandler must initialize the ExecuteRequestContext before responding
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1002
>                 URL: https://issues.jboss.org/browse/WFCORE-1002
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> If in a race a COMPLETE_TX_REQUEST cancelling an op is processed by a server/slave HC before the original EXECUTE_TX_REQUEST is processed, when the EXECUTE_TX_REQUEST comes in the AbortOperationHandler attempts to respond with a "outcome"=>"cancelled" response. This will fail because the ExecutionRequestContext will not be initialized.
> In this situation the AbortOperationHandler should initialize the ERC.
> With assertions enabled, this appears in the log:
> {code}
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) Exception in thread "Remoting "slave:main-three:MANAGEMENT" task-6" java.lang.AssertionError
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:458)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$AbortOperationHandler.handleRequest(TransactionalProtocolOperationHandler.java:275)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:705)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Without assertions, a few lines later a call to sendResponse will result in an NPE.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 20:51:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 20:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1002)
 TransactionalProtocolOperationHandler.AbortOperationHandler must initialize
 the ExecuteRequestContext before responding
In-Reply-To: <JIRA.12585720.1442956922000@Atlassian.JIRA>
References: <JIRA.12585720.1442956922000@Atlassian.JIRA>
	<JIRA.12585720.1442956922000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585720.1442956922000.6105.1442969460300@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1002:
-------------------------------------
    Fix Version/s: 2.0.0.CR4


> TransactionalProtocolOperationHandler.AbortOperationHandler must initialize the ExecuteRequestContext before responding
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1002
>                 URL: https://issues.jboss.org/browse/WFCORE-1002
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR4
>
>
> If in a race a COMPLETE_TX_REQUEST cancelling an op is processed by a server/slave HC before the original EXECUTE_TX_REQUEST is processed, when the EXECUTE_TX_REQUEST comes in the AbortOperationHandler attempts to respond with a "outcome"=>"cancelled" response. This will fail because the ExecutionRequestContext will not be initialized.
> In this situation the AbortOperationHandler should initialize the ERC.
> With assertions enabled, this appears in the log:
> {code}
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) Exception in thread "Remoting "slave:main-three:MANAGEMENT" task-6" java.lang.AssertionError
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:458)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$AbortOperationHandler.handleRequest(TransactionalProtocolOperationHandler.java:275)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:705)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Without assertions, a few lines later a call to sendResponse will result in an NPE.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 21:34:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Sep 2015 21:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5368) WFLYSRV0099: 'myappname:main'
 cannot be loaded from a ServiceModuleLoader as its name does not start with
 'deployment.'
In-Reply-To: <JIRA.12585392.1442585021000@Atlassian.JIRA>
References: <JIRA.12585392.1442585021000@Atlassian.JIRA>
	<JIRA.12585392.1442585021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585392.1442585021000.6115.1442972040191@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-5368:
------------------------------------

    Component/s: Class Loading
                     (was: Web (JBoss Web))
       Assignee: Stuart Douglas  (was: Remy Maucherat)


> WFLYSRV0099: 'myappname:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5368
>                 URL: https://issues.jboss.org/browse/WFLY-5368
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 9.0.1.Final
>         Environment: Windows 7 Ultimate
> JDK 1.7.0_55 (Oracle)
>            Reporter: Jan Moravec
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: server.log
>
>
> Hello,
> I am moving our apps from JBoss 7 Community to WildFly 9.0.1 and hitting the following error during the deployment of our apps:
> WFLYSRV0099: 'quartzdesk-test-quartz-v2-2-x-logback:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'
> I tried 2 different applications that all work without any problem on various popular application servers/containers, but with the same result. I tried to google this error, but did not find much information.
> Any idea what is going on?
> Many thanks.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 21:36:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Sep 2015 21:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5368) WFLYSRV0099: 'myappname:main'
 cannot be loaded from a ServiceModuleLoader as its name does not start with
 'deployment.'
In-Reply-To: <JIRA.12585392.1442585021000@Atlassian.JIRA>
References: <JIRA.12585392.1442585021000@Atlassian.JIRA>
	<JIRA.12585392.1442585021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585392.1442585021000.6118.1442972160125@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111526#comment-13111526 ] 

Stuart Douglas commented on WFLY-5368:
--------------------------------------

Your jboss-deployment-structure.xml contains the following line:

    <module-alias name="quartzdesk-test-quartz-v2-2-x-logback"/>

aliases installed by deployments need to start with the name "deployment.". 

You can probably just delete this line, I doubt it is necessary.

> WFLYSRV0099: 'myappname:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5368
>                 URL: https://issues.jboss.org/browse/WFLY-5368
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 9.0.1.Final
>         Environment: Windows 7 Ultimate
> JDK 1.7.0_55 (Oracle)
>            Reporter: Jan Moravec
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: server.log
>
>
> Hello,
> I am moving our apps from JBoss 7 Community to WildFly 9.0.1 and hitting the following error during the deployment of our apps:
> WFLYSRV0099: 'quartzdesk-test-quartz-v2-2-x-logback:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'
> I tried 2 different applications that all work without any problem on various popular application servers/containers, but with the same result. I tried to google this error, but did not find much information.
> Any idea what is going on?
> Many thanks.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 21:41:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Sep 2015 21:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5368) WFLYSRV0099: 'myappname:main'
 cannot be loaded from a ServiceModuleLoader as its name does not start with
 'deployment.'
In-Reply-To: <JIRA.12585392.1442585021000@Atlassian.JIRA>
References: <JIRA.12585392.1442585021000@Atlassian.JIRA>
	<JIRA.12585392.1442585021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585392.1442585021000.6121.1442972460302@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-5368.
----------------------------------
    Resolution: Rejected


> WFLYSRV0099: 'myappname:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5368
>                 URL: https://issues.jboss.org/browse/WFLY-5368
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 9.0.1.Final
>         Environment: Windows 7 Ultimate
> JDK 1.7.0_55 (Oracle)
>            Reporter: Jan Moravec
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: server.log
>
>
> Hello,
> I am moving our apps from JBoss 7 Community to WildFly 9.0.1 and hitting the following error during the deployment of our apps:
> WFLYSRV0099: 'quartzdesk-test-quartz-v2-2-x-logback:main' cannot be loaded from a ServiceModuleLoader as its name does not start with 'deployment.'
> I tried 2 different applications that all work without any problem on various popular application servers/containers, but with the same result. I tried to google this error, but did not find much information.
> Any idea what is going on?
> Many thanks.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1002)
 TransactionalProtocolOperationHandler.AbortOperationHandler must initialize
 the ExecuteRequestContext before responding
In-Reply-To: <JIRA.12585720.1442956922000@Atlassian.JIRA>
References: <JIRA.12585720.1442956922000@Atlassian.JIRA>
	<JIRA.12585720.1442956922000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585720.1442956922000.6274.1442974920582@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1002:
-------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> TransactionalProtocolOperationHandler.AbortOperationHandler must initialize the ExecuteRequestContext before responding
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1002
>                 URL: https://issues.jboss.org/browse/WFCORE-1002
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR5
>
>
> If in a race a COMPLETE_TX_REQUEST cancelling an op is processed by a server/slave HC before the original EXECUTE_TX_REQUEST is processed, when the EXECUTE_TX_REQUEST comes in the AbortOperationHandler attempts to respond with a "outcome"=>"cancelled" response. This will fail because the ExecutionRequestContext will not be initialized.
> In this situation the AbortOperationHandler should initialize the ERC.
> With assertions enabled, this appears in the log:
> {code}
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) Exception in thread "Remoting "slave:main-three:MANAGEMENT" task-6" java.lang.AssertionError
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:458)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$AbortOperationHandler.handleRequest(TransactionalProtocolOperationHandler.java:275)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:705)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Without assertions, a few lines later a call to sendResponse will result in an NPE.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1001) Starting embedded server
 overwrites standalone/config/logging.properties with a mostly blank config
In-Reply-To: <JIRA.12585689.1442943974000@Atlassian.JIRA>
References: <JIRA.12585689.1442943974000@Atlassian.JIRA>
	<JIRA.12585689.1442943974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585689.1442943974000.6277.1442974920672@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1001:
-------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> Starting embedded server overwrites standalone/config/logging.properties with a mostly blank config
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1001
>                 URL: https://issues.jboss.org/browse/WFCORE-1001
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR5
>
>
> Note the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties
>  $ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> Check the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties, the file is empty.
> Starting standalone will restore the default contents.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.6281.1442974920771@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-994:
------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-989) Premature registration of
 reconnecting server
In-Reply-To: <JIRA.12585427.1442632267000@Atlassian.JIRA>
References: <JIRA.12585427.1442632267000@Atlassian.JIRA>
	<JIRA.12585427.1442632267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585427.1442632267000.6283.1442974920819@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-989:
------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> Premature registration of reconnecting server
> ---------------------------------------------
>
>                 Key: WFCORE-989
>                 URL: https://issues.jboss.org/browse/WFCORE-989
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR5
>
>
> ServerInventoryImpl.reconnectServer is registering the ProxyController for the reconnecting server with the DomainModelControllerService. The problem is that ProxyController is not yet in a state where it can forward requests to the server. That won't happen until the server calls back with a DomainServerProtocol.SERVER_RECONNECT_REQUEST and the ServerToHostProtocolHandler.ServerReconnectRequestHandler handles it. The effect is if a request for the server comes in during this window, it will fail. If that request is part of a domain operation rollout (because during the window the HC regarded the server as 'live' and instructed the DC to send rollout ops to it), then the domain rollout will be affected. This happened in the testsuite failure I just saw. Most significant logging is as follows:
> {code}
> 2015-09-18 17:59:32,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" (Host Controller) started in 93ms - Started 48 of 51 services (15 services are lazy, passive or on-demand)
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-16) Initialized for 1849055188
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-14) WFLYHC0021: Server [Server:main-three] connected using connection [Channel ID 08aa200b (inbound) of Remoting connection 27e3d90d to /127.0.0.1:49272]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-15) WFLYHC0021: Server [Server:other-two] connected using connection [Channel ID 02bd2646 (inbound) of Remoting connection 64a8b7f2 to /127.0.0.1:49273]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) Initialized for 1849055188
> 2015-09-18 17:59:32,252 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) sending prepared response for 1849055188  --- interrupted: false
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 481103151
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) Initialized for 481103151
> 2015-09-18 17:59:32,255 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) sending pre-prepare failed response for 1933145457  --- interrupted: false
> 2015-09-18 17:59:32,256 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) sending pre-prepare failed response for 481103151  --- interrupted: false
> {code}
> The HC completes boot. Then servers main-three and other-two register. The HC sends a prepared response to a request. This is the host rollout request to the slave from the DC with the response being the ops to invoke on the servers. The HC reports sending a "pre-prepare failed response" to two requests. These are the requests the DC has asked it to proxy to the servers.
> The result of all this for the client is the following failure of a management op:
> {code}
> Failed operation:
> {
>     "operation" => "add",
>     "address" => [("extension" => "org.jboss.as.test.hc.extension")]
> }
> Response:
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"slave" => {"main-three" => "WFLYHC0153: Channel closed"}}},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => "WFLYHC0153: Channel closed"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {
>             "master" => {"main-one" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => [("HC" => "1.1.1")],
>                 "rolled-back" => true
>             }}},
>             "slave" => {"main-three" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => undefined,
>                 "failure-description" => "WFLYHC0153: Channel closed",
>                 "rolled-back" => true
>             }}}
>         }},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYHC0153: Channel closed",
>             "rolled-back" => true
>         }}}}}
>     }
> }
> {code}
> The "WFLYHC0153: Channel closed" failure is what is produced when an attempt is made to invoke on a disconnected proxy controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.6287.1442974920930@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-988:
------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR5
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.6290.1442974921012@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-979:
------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
>                 Key: WFCORE-979
>                 URL: https://issues.jboss.org/browse/WFCORE-979
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR5
>
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
>  testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >  
> >      <domain-controller>
> >          <!-- Remote domain controller configuration with a host and port -->
> > -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-932) stop-embedded-server stops
 the embedded host controller and vice versa
In-Reply-To: <JIRA.12583124.1440765129000@Atlassian.JIRA>
References: <JIRA.12583124.1440765129000@Atlassian.JIRA>
	<JIRA.12583124.1440765129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583124.1440765129000.6294.1442974921087@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-932:
------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> stop-embedded-server stops the embedded host controller and vice versa
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-932
>                 URL: https://issues.jboss.org/browse/WFCORE-932
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Ken Wills
>            Priority: Minor
>             Fix For: 2.0.0.CR5
>
>
> We have four new commands for controlling the lifecycle of embedded instances:
> * *embed-server* - launch embedded standalone
> * *stop-embedded-server* - stop embedded standalone
> * *embed-host-controller* - launch embedded host
> * *stop-embedded-host-controller* - stop embedded host
> \\
> I am able stop embedded standalone by *stop-embedded-host-controller* and embedded host controller by *stop-embedded-server*.
> {noformat}
> [disconnected /] embed-server 
> [standalone at embedded /] stop-embedded-host-controller 
> [disconnected /] embed-host-controller 
> 14:22:18,781 INFO  [org.jboss.modules] (AeshProcess: 15) JBoss Modules version 1.4.3.Final
> [domain at embedded /] stop-embedded-server 
> [disconnected /]
> {noformat}
> \\
> A question comes to my mind, do we need two commands for stopping the embedded instance?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 22:22:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 22 Sep 2015 22:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.6301.1442974921296@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-756:
------------------------------------
    Fix Version/s: 2.0.0.CR5
                       (was: 2.0.0.CR4)


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>         Attachments: server.log, server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 22 23:46:01 2015
From: issues at jboss.org (Laurent Pellegrino (JIRA))
Date: Tue, 22 Sep 2015 23:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-248) Constant pool index 268 is
	invalid
In-Reply-To: <JIRA.12577796.1436778937000@Atlassian.JIRA>
References: <JIRA.12577796.1436778937000@Atlassian.JIRA>
	<JIRA.12577796.1436778937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577796.1436778937000.6339.1442979961085@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111536#comment-13111536 ] 

Laurent Pellegrino commented on JASSIST-248:
--------------------------------------------

[~chiba] Thank you for your answer. The stub is generated by the class below:

https://github.com/ow2-proactive/programming/blob/proactive-light/programming-core/src/main/java/org/objectweb/proactive/core/mop/JavassistByteCodeStubBuilder.java

What do you suggest for the fix? to ignore from the generator default methods declared in an interface so that they are not added in the stub?

> Constant pool index 268 is invalid
> ----------------------------------
>
>                 Key: JASSIST-248
>                 URL: https://issues.jboss.org/browse/JASSIST-248
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.19.0-GA
>            Reporter: Laurent Pellegrino
>            Assignee: Shigeru Chiba
>              Labels: regression
>         Attachments: _StubLinkedList.class
>
>
> We are using Javassist for one of our open source projects since about 10 years. Recently, I have tried to upgrade to version 3.19 and 3.20. Unfortunately, with both versions, generated byte code seems to cause errors with the JVM.
> Below is the output:
> {code}
> Exception in thread "RestartDownNodesPolicy node status check" java.lang.VerifyError: Illegal type at constant pool entry 268 in class pa.stub.java.util._StubLinkedList
> Exception Details:
>   Location:
>     pa/stub/java/util/_StubLinkedList.replaceAll(Ljava/util/function/UnaryOperator;)V @43: invokespecial
>   Reason:
>     Constant pool index 268 is invalid
>   Bytecode:
>     0x0000000: 2ab4 00cc 9900 252a b400 0db2 002c 100b
>     0x0000010: 32c0 0028 04bd 00ce 5903 2b53 b200 26b8
>     0x0000020: 00d7 b900 dd02 0057 b12a 2bb7 010c b1  
>   Stackmap Table:
>     same_frame(@41)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:264)
> 	at org.objectweb.proactive.core.mop.MOP.forName(MOP.java:155)
> 	at org.objectweb.proactive.core.mop.MOP.findStubConstructor(MOP.java:649)
> 	at org.objectweb.proactive.core.mop.MOP.createStubObject(MOP.java:822)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:338)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:196)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reifyAsAsynchronous(AbstractBodyProxy.java:277)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.invokeOnBody(AbstractBodyProxy.java:154)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reify(AbstractBodyProxy.java:123)
> 	at pa.stub.org.ow2.proactive.resourcemanager.nodesource._StubNodeSource.getDownNodes(_StubNodeSource.java)
> 	at org.ow2.proactive.resourcemanager.nodesource.policy.RestartDownNodesPolicy$1.run(RestartDownNodesPolicy.java:92)
> 	at java.util.TimerThread.mainLoop(Timer.java:555)
> 	at java.util.TimerThread.run(Timer.java:505)
> {code}
> The issue seems related to default methods introduced in Java 8. Perhaps its not an issue with Javassist but to be honest I don't understand the exception.  However, I have noticed that using Javassist in version 3.18.2 solves the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 01:04:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Wed, 23 Sep 2015 01:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.6348.1442984640104@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111538#comment-13111538 ] 

Petr Kremensky commented on WFCORE-993:
---------------------------------------

[~luck3y] sorry for that, I tested this with the latest EAP build, WF CR1, but not with the latest core. 

I tested the wf-core releases and this issue was fixed with wf-core 2.0.0.CR2. [Upstream|https://github.com/wildfly/wildfly/blob/master/pom.xml] contains CR4 as dependency so hopefully next EAP build will be fine as well.


> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>            Priority: Critical
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 01:05:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Wed, 23 Sep 2015 01:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.6351.1442984700196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Kremensky updated WFCORE-993:
----------------------------------
    Fix Version/s: 2.0.0.CR2


> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 01:05:00 2015
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Wed, 23 Sep 2015 01:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-993) Reload command on
 embed-host-controller fails
In-Reply-To: <JIRA.12585486.1442834978000@Atlassian.JIRA>
References: <JIRA.12585486.1442834978000@Atlassian.JIRA>
	<JIRA.12585486.1442834978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585486.1442834978000.6354.1442984700267@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Kremensky resolved WFCORE-993.
-----------------------------------
    Resolution: Done


> Reload command on embed-host-controller fails
> ---------------------------------------------
>
>                 Key: WFCORE-993
>                 URL: https://issues.jboss.org/browse/WFCORE-993
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>            Priority: Critical
>             Fix For: 2.0.0.CR2
>
>
> Reload operation on embed-host-controller gives me an error.
> {noformat}
> [disconnected /] embed-host-controller 
> [domain at embedded /] reload --host=master
> 13:25:30,019 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 6ms
> 13:25:30,020 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 13:25:30,115 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,138 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=default/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,150 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,166 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,167 ERROR [org.jboss.as.controller] (AeshProcess: 2) WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-mping in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-tcp-fd in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.http in context 'profile=default'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.ajp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.network.socket-binding.jgroups-udp in context 'profile=ha'; There are no known registration points which can provide this capability.
>     org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> 13:25:30,178 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'enabled' in the resource at address '/profile=full-ha/subsystem=datasources/data-source=ExampleDS' 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.
> 13:25:30,196 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/server-group=main-server-group' are not available:
>     org.wildfly.domain.profile.full in context 'server-groups'; There are no known registration points which can provide this capability.
> 13:25:30,198 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 13:25:30,204 ERROR [org.jboss.as.protocol] (Thread-2) WFLYPRT0003: Failed to close resource org.jboss.as.cli.embedded.ThreadContextsModelControllerClient at 713124ae: java.lang.IllegalStateException: WFLYEMB0023: The embedded server is stopping and invocations on the ModelControllerClient are not available
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.getActiveModelControllerClient(EmbeddedHostControllerFactory.java:331)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl.access$200(EmbeddedHostControllerFactory.java:225)
> 	at org.wildfly.core.embedded.EmbeddedHostControllerFactory$HostControllerImpl$3.getDelegate(EmbeddedHostControllerFactory.java:309)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.close(DelegatingModelControllerClient.java:103)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.close(ThreadContextsModelControllerClient.java:139)
> 	at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
> 	at org.jboss.as.cli.impl.CommandContextImpl.disconnectController(CommandContextImpl.java:1181)
> 	at org.jboss.as.cli.impl.CommandContextImpl.terminateSession(CommandContextImpl.java:812)
> 	at org.jboss.as.cli.impl.CommandContextImpl$1.shutdown(CommandContextImpl.java:370)
> 	at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> 	at java.lang.Thread.run(Thread.java:745)
> 13:25:30,215 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) stopped in 11ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 02:06:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 23 Sep 2015 02:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.6371.1442988360073@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-979:
-----------------------------
    Fix Version/s:     (was: 2.0.0.CR5)


> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
>                 Key: WFCORE-979
>                 URL: https://issues.jboss.org/browse/WFCORE-979
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
>  testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >  
> >      <domain-controller>
> >          <!-- Remote domain controller configuration with a host and port -->
> > -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 02:08:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 23 Sep 2015 02:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-979) ignore-unused-configuration
 default value change testsuite changes.
In-Reply-To: <JIRA.12584729.1441993242000@Atlassian.JIRA>
References: <JIRA.12584729.1441993242000@Atlassian.JIRA>
	<JIRA.12584729.1441993242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584729.1441993242000.6373.1442988480047@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111541#comment-13111541 ] 

Ken Wills commented on WFCORE-979:
----------------------------------

I'll be working on this change tomorrow, but I don't think we need to have it for CR5 or final. 

> ignore-unused-configuration default value change testsuite changes.
> -------------------------------------------------------------------
>
>                 Key: WFCORE-979
>                 URL: https://issues.jboss.org/browse/WFCORE-979
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> This is a continuation of WFCORE-310, covering testsuite changes, post CR1.
> From [~brian.stansberry]:
>  testsuite/domain/src/test/resources/host-configs/host-minimal.xml:
> > @@ -59,7 +59,7 @@
> >  
> >      <domain-controller>
> >          <!-- Remote domain controller configuration with a host and port -->
> > -        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm">
> > +        <remote host="${jboss.test.host.master.address}" port="9999" security-realm="ManagementRealm" ignore-unused-configuration="false">
> My comment here is more of a note for probably post CR1 work.
> This file is used in ProductInfoUnitTestCase and ServerManagementTestCase.
> For ProductInfoUnitTestCase it shouldn't matter which setting the file has, so changing it to match what other tests need is fine.
> ServerManagementTestCase is pretty messy. It has tests related to server lifecycle. Ideally those would be tested with "ignoring" set both ways, as a big part of the functionality here involves the HC having or obtaining the necessary config data as servers are added. The class also has tests related to profile cloning, and profile and socket-binding-group includes. One of these, testCloneProfile() just won't work if the slave is ignoring, but it doesn't really belong in this class anyway, as server management is not a factor in the test. It should be moved out, or perhaps have the slave assert changed if the slave is ignoring. For some of the others, server management is relevant, but they would need to be reworked to properly test things if the slave is ignoring. Basically, check that "config present" != ignoring, and then add the server config and check that "config present" == true. Where "config" is the profile/s-b-g/server-group in question.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 02:09:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 23 Sep 2015 02:09:00 -0400 (EDT)
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.1442988528219@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585731.1442988528000.6376.1442988540145@Atlassian.JIRA>

Tom Jenkinson created WFLY-5387:
-----------------------------------

             Summary: 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: Michael Musgrove
             Fix For: 10.0.0.CR2


Includes miscellaneous bug fixes 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 02:47:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 02:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.6411.1442990820124@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111546#comment-13111546 ] 

Heiko Braun commented on WFCORE-998:
------------------------------------

[~brian.stansberry] But shouldn't a :rrd() op be executed regardless if the server is running or not?

> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 03:45:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 23 Sep 2015 03:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5353) Unable to set resolve-hosts
	for access-log
In-Reply-To: <JIRA.12585103.1442406697000@Atlassian.JIRA>
References: <JIRA.12585103.1442406697000@Atlassian.JIRA>
	<JIRA.12585103.1442406697000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585103.1442406697000.6481.1442994300168@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-5353.
----------------------------------
    Fix Version/s: 10.0.0.CR2
       Resolution: Done


> Unable to set resolve-hosts for access-log
> ------------------------------------------
>
>                 Key: WFLY-5353
>                 URL: https://issues.jboss.org/browse/WFLY-5353
>             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.CR2
>
>
> In previous versions of EAP (Web subsystem) there was possible to enable resolving hosts for access logging. This is not possible to enable with Undertow.
> Steps for enabling in JBoss Web:
> This was accomplished by setting {{resolve-hosts}} attribute of access-log to {{true}} ({{/subsystem=web/virtual-server=default-host/configuration=access-log:add(resolve-hosts=true)}}) and enabling lookups for connector ({{/subsystem=web/connector=http:write-attribute(name=enable-lookups, value=true)}}).
> In Undertow subsystem there is only possible to enable resolving peer address ({{/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=resolve-peer-address, value=true)}}), which doesn't have by itself any impact on output in access-log



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 03:55:00 2015
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Wed, 23 Sep 2015 03:55:00 -0400 (EDT)
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.6514.1442994900152@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Emerson reassigned WFLY-5232:
----------------------------------

      Assignee: Ryan Emerson  (was: Jason Greene)
    Resolution: Done


> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 04:58:00 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 04:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-877) Redirection (<,
	<<) do not work in CLI
In-Reply-To: <JIRA.12580981.1439385810000@Atlassian.JIRA>
References: <JIRA.12580981.1439385810000@Atlassian.JIRA>
	<JIRA.12580981.1439385810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580981.1439385810000.6596.1442998680220@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? reopened WFCORE-877:
----------------------------------


This issue is still valid in WildFly Core 2.0.0.CR3

> Redirection (<, <<) do not work in CLI
> --------------------------------------
>
>                 Key: WFCORE-877
>                 URL: https://issues.jboss.org/browse/WFCORE-877
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Marek Kopeck?
>            Assignee: Joe Wertz
>            Priority: Blocker
>             Fix For: 2.0.0.Beta6
>
>
> *Description of problem:*
> Redirection (<, <<) do not work in CLI
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # echo ":shutdown" > c
> # ./jboss-cli.sh -c < c
> *Actual results:*
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> *Expected results:*
> ":shutdown" command will be executed
> *Another steps to reproduce:*
> # cd bin
> # ./standalone.sh &
> # ./jboss-cli.sh -c command=/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
> # ./jboss-cli.sh -c command=/core-service=management/security-realm=ManagementRealm/authentication=local:remove
> # ./jboss-cli.sh -c command=:shutdown
> # cd ..
> # echo "bob=81ce18184f7b1095a367d5fae624ac15" >> standalone/configuration/mgmt-users.properties
> # ./bin/standalone.sh &
> # {noformat}./bin/jboss-cli.sh -c <<EOF
> bob
> admin123$
> batch
> :shutdown
> run-batch
> EOF{noformat}
> *Actual results:*
> Unexpected command 'bob'. Type 'help --commands' for the list of supported commands.
> *Expected results:*
> ":shutdown" command will be executed
> *Additional info:*
> Regression against 6.4.0
> Regression against 7.0.0.DR7
> Bugzilla from 6x
> * https://bugzilla.redhat.com/show_bug.cgi?id=961425
> Customer cases (EAP 6x):
> * https://access.redhat.com/support/cases/#/case/00904577
> * https://access.redhat.com/support/cases/#/case/00889193
> * https://access.redhat.com/support/cases/#/case/00910827
> * https://access.redhat.com/support/cases/#/case/00910848



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 05:33:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 23 Sep 2015 05:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-311) Odd rules execution for
	expired events
In-Reply-To: <JIRA.12469400.1340610279000@Atlassian.JIRA>
References: <JIRA.12469400.1340610279000@Atlassian.JIRA>
	<JIRA.12469400.1340610279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469400.1340610279000.6681.1443000780302@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-311:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)


> Odd rules execution for expired events
> --------------------------------------
>
>                 Key: DROOLS-311
>                 URL: https://issues.jboss.org/browse/DROOLS-311
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>         Environment: Windows Vista 64, JRE6 (x86)
>            Reporter: Karol Sobczak
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: expiredrules.zip
>
>
> I have declared two types:
> declare Motion
>   @role( event )
>   @expires( 5s )
>   @timestamp( eventTime )
>   eventTime : long
> end
> declare Recording
> end
> and following rules:
> rule "StartRecording"
>   when
>     Motion()
>     not Recording()
>   then
>     insert(new Recording())
> end
> the problem is that when I put a lot of "Motions", sleep (so "Motions" become expired) and then do fireAllRules(), I got "StartRecording" executed multiple times (and not only once), event though "Recording" is inserted every time. 
> Another issue would be when instead of "StartRecording" rule I would have "StopRecording" rule:
> rule "StopRecording"
>   when
>     $m : Motion()
>     $r : Recording()
>   then
>     System.err.println("Recording: " + $r);
>     retract($r);
> end 
> then when there is a "Recording" fact inserted and multiple expired "Motions", the rule would be executed multiple times (when "Motions" expire) and $r would be null after the first "StopRecording" rule execution.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 05:36:00 2015
From: issues at jboss.org (Matyas Danter (JIRA))
Date: Wed, 23 Sep 2015 05:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5388) Intermittent
 java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided
 undertow and resteasy
In-Reply-To: <JIRA.12585747.1443000917000@Atlassian.JIRA>
References: <JIRA.12585747.1443000917000@Atlassian.JIRA>
	<JIRA.12585747.1443000917549@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585747.1443000917000.6693.1443000960433@Atlassian.JIRA>

Matyas Danter created WFLY-5388:
-----------------------------------

             Summary: Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow and resteasy
                 Key: WFLY-5388
                 URL: https://issues.jboss.org/browse/WFLY-5388
             Project: WildFly
          Issue Type: Bug
          Components: REST, Web (Undertow)
    Affects Versions: 10.0.0.CR1, 9.0.1.Final, 8.2.1.Final
            Reporter: Matyas Danter
            Assignee: Stuart Douglas


When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .

The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 05:52:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Kalman_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 05:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5389) NPE during activation of
 backup server in collocated replicated topology
In-Reply-To: <JIRA.12585750.1443001912000@Atlassian.JIRA>
References: <JIRA.12585750.1443001912000@Atlassian.JIRA>
	<JIRA.12585750.1443001912987@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585750.1443001912000.6707.1443001920151@Atlassian.JIRA>

Ond?ej Kalman created WFLY-5389:
-----------------------------------

             Summary: NPE during activation of backup server in collocated replicated topology
                 Key: WFLY-5389
                 URL: https://issues.jboss.org/browse/WFLY-5389
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 10.0.0.CR1
            Reporter: Ond?ej Kalman
            Assignee: Clebert Suconic


I'm getting this exception when one of nodes in collocated replicated topology fails and backup is trying to get up.
11:41:44,643 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: java.lang.NullPointerException
at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
11:41:44,644 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) java.lang.NullPointerException
11:41:44,644 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
11:41:44,645 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at java.lang.Thread.run(Thread.java:745)




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 06:13:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 23 Sep 2015 06:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5390) Fix intermittent failures in
 ClusteredMessagingTestCase
In-Reply-To: <JIRA.12585751.1443003130000@Atlassian.JIRA>
References: <JIRA.12585751.1443003130000@Atlassian.JIRA>
	<JIRA.12585751.1443003130140@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585751.1443003130000.6743.1443003180079@Atlassian.JIRA>

Jeff Mesnil created WFLY-5390:
---------------------------------

             Summary: Fix intermittent failures in ClusteredMessagingTestCase
                 Key: WFLY-5390
                 URL: https://issues.jboss.org/browse/WFLY-5390
             Project: WildFly
          Issue Type: Bug
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


Test are ignored since https://github.com/wildfly/wildfly/pull/8174



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 06:23:00 2015
From: issues at jboss.org (Matyas Danter (JIRA))
Date: Wed, 23 Sep 2015 06:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5388) Intermittent
 java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided
 undertow, resteasy, and jackson
In-Reply-To: <JIRA.12585747.1443000917000@Atlassian.JIRA>
References: <JIRA.12585747.1443000917000@Atlassian.JIRA>
	<JIRA.12585747.1443000917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585747.1443000917000.6773.1443003780176@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matyas Danter updated WFLY-5388:
--------------------------------
    Summary: Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson  (was: Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow and resteasy)


> Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5388
>                 URL: https://issues.jboss.org/browse/WFLY-5388
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST, Web (Undertow)
>    Affects Versions: 8.2.1.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Matyas Danter
>            Assignee: Stuart Douglas
>
> When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .
> The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 06:33:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 23 Sep 2015 06:33:00 -0400 (EDT)
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.6798.1443004380203@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5387:
--------------------------------
    Fix Version/s:     (was: 10.0.0.CR2)


> 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: Michael Musgrove
>
> Includes miscellaneous bug fixes 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 06:33:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 23 Sep 2015 06:33:00 -0400 (EDT)
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.6803.1443004380375@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson reassigned WFLY-5387:
-----------------------------------

    Assignee: Tom Jenkinson  (was: Michael Musgrove)


> 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
>
> Includes miscellaneous bug fixes 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 06:43:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Sep 2015 06:43:00 -0400 (EDT)
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.6823.1443004980088@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111610#comment-13111610 ] 

RH Bugzilla Integration commented on WFLY-4876:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1240537|https://bugzilla.redhat.com/show_bug.cgi?id=1240537] from ON_QA to VERIFIED

> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 06:52:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Sep 2015 06:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-285) cli tab completion gets
 confused by double slash
In-Reply-To: <JIRA.12557423.1415975102000@Atlassian.JIRA>
References: <JIRA.12557423.1415975102000@Atlassian.JIRA>
	<JIRA.12557423.1415975102000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557423.1415975102000.6848.1443005520329@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111614#comment-13111614 ] 

RH Bugzilla Integration commented on WFCORE-285:
------------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1164277|https://bugzilla.redhat.com/show_bug.cgi?id=1164277] from ON_QA to VERIFIED

> cli tab completion gets confused by double slash
> ------------------------------------------------
>
>                 Key: WFCORE-285
>                 URL: https://issues.jboss.org/browse/WFCORE-285
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 1.0.0.Alpha13
>            Reporter: Tom Fonteyne
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>             Fix For: 1.0.0.Alpha14
>
>
> Using two slashes in a CLI path and hitting TAB confuses the auto-completion



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 06:54:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Sep 2015 06:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1003) Cosmetic Schema Sync
In-Reply-To: <JIRA.12585760.1443005582000@Atlassian.JIRA>
References: <JIRA.12585760.1443005582000@Atlassian.JIRA>
	<JIRA.12585760.1443005582316@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585760.1443005582000.6851.1443005640147@Atlassian.JIRA>

Darran Lofthouse created WFCORE-1003:
----------------------------------------

             Summary: Cosmetic Schema Sync
                 Key: WFCORE-1003
                 URL: https://issues.jboss.org/browse/WFCORE-1003
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 2.0.0.CR5






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 07:09:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Sep 2015 07:09:00 -0400 (EDT)
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.6882.1443006540125@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111619#comment-13111619 ] 

RH Bugzilla Integration commented on WFLY-5221:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1257612|https://bugzilla.redhat.com/show_bug.cgi?id=1257612] from ON_QA to VERIFIED

> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 07:14:00 2015
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 23 Sep 2015 07:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4959) Log INFO message when a
 security manager is activated
In-Reply-To: <JIRA.12578435.1437138658000@Atlassian.JIRA>
References: <JIRA.12578435.1437138658000@Atlassian.JIRA>
	<JIRA.12578435.1437138658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578435.1437138658000.6899.1443006840187@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111622#comment-13111622 ] 

Ivo Studensky commented on WFLY-4959:
-------------------------------------

Can this be logged from jboss-modules Main class when it is setting a security manager?

> Log INFO message when a security manager is activated
> -----------------------------------------------------
>
>                 Key: WFLY-4959
>                 URL: https://issues.jboss.org/browse/WFLY-4959
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>
> When the server is started with security manager enabled, a message with this information should be logged. IMO the {{INFO}} log-level is the best option here.
> [~dmlloyd] says in [WFLY-403|https://issues.jboss.org/browse/WFLY-403?focusedCommentId=12755871&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12755871]:
> ??When a security manager is activated (whether by admin or at boot), a log message should announce that a security manager is now in force.??



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 07:21:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Sep 2015 07:21:00 -0400 (EDT)
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.6909.1443007260463@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111625#comment-13111625 ] 

RH Bugzilla Integration commented on WFLY-4625:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1243553|https://bugzilla.redhat.com/show_bug.cgi?id=1243553] from ON_QA to VERIFIED

> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 07:35:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Sep 2015 07:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4528) Product to Project Schema and
	Model Sync
In-Reply-To: <JIRA.12568718.1429281553000@Atlassian.JIRA>
References: <JIRA.12568718.1429281553000@Atlassian.JIRA>
	<JIRA.12568718.1429281553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568718.1429281553000.6948.1443008100443@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-4528.
------------------------------------
    Resolution: Done


> Product to Project Schema and Model Sync
> ----------------------------------------
>
>                 Key: WFLY-4528
>                 URL: https://issues.jboss.org/browse/WFLY-4528
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR2
>
>
> Periodic sync of EAP schemas with WildFly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 07:35:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Sep 2015 07:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3681) General Schema Sync with EAP
In-Reply-To: <JIRA.12547683.1406573811000@Atlassian.JIRA>
References: <JIRA.12547683.1406573811000@Atlassian.JIRA>
	<JIRA.12547683.1406573811000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547683.1406573811000.6953.1443008100614@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-3681.
------------------------------------
    Resolution: Done


> General Schema Sync with EAP
> ----------------------------
>
>                 Key: WFLY-3681
>                 URL: https://issues.jboss.org/browse/WFLY-3681
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> This may actually be more about pushing some changes to EAP, new schemas are being tracked by individual issues but for the remaining schemas where cosmetic changes have been made or corrections to default values and min/max occurs we need to sync with EAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:01:04 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 08:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.7018.1443009664380@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reopened WFCORE-998:
--------------------------------
      Assignee: Brian Stansberry  (was: Heiko Braun)


> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:03:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 23 Sep 2015 08:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4959) Log INFO message when a
 security manager is activated
In-Reply-To: <JIRA.12578435.1437138658000@Atlassian.JIRA>
References: <JIRA.12578435.1437138658000@Atlassian.JIRA>
	<JIRA.12578435.1437138658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578435.1437138658000.7026.1443009780378@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111637#comment-13111637 ] 

David Lloyd commented on WFLY-4959:
-----------------------------------

Sure, it's possible.  It would have to be logged *after* the log manager is set up though.

> Log INFO message when a security manager is activated
> -----------------------------------------------------
>
>                 Key: WFLY-4959
>                 URL: https://issues.jboss.org/browse/WFLY-4959
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>
> When the server is started with security manager enabled, a message with this information should be logged. IMO the {{INFO}} log-level is the best option here.
> [~dmlloyd] says in [WFLY-403|https://issues.jboss.org/browse/WFLY-403?focusedCommentId=12755871&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12755871]:
> ??When a security manager is activated (whether by admin or at boot), a log message should announce that a security manager is now in force.??



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:09:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 23 Sep 2015 08:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5391) Access logging doesn't
 recognize common pattern
In-Reply-To: <JIRA.12585767.1443010134000@Atlassian.JIRA>
References: <JIRA.12585767.1443010134000@Atlassian.JIRA>
	<JIRA.12585767.1443010134095@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585767.1443010134000.7048.1443010140557@Atlassian.JIRA>

Radim Hatlapatka created WFLY-5391:
--------------------------------------

             Summary: Access logging doesn't recognize common pattern
                 Key: WFLY-5391
                 URL: https://issues.jboss.org/browse/WFLY-5391
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Critical


When having defined default access logging (just changing {{extended}} attribute to {{false}}), instead of logging according to common pattern (the default pattern), only the word "common" is logged per each request.

Marking as critical as this is behaviour with default access-log configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:10:00 2015
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 23 Sep 2015 08:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5391) Access logging doesn't
 recognize common pattern
In-Reply-To: <JIRA.12585767.1443010134000@Atlassian.JIRA>
References: <JIRA.12585767.1443010134000@Atlassian.JIRA>
	<JIRA.12585767.1443010134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585767.1443010134000.7051.1443010200171@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-5391:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> Access logging doesn't recognize common pattern
> -----------------------------------------------
>
>                 Key: WFLY-5391
>                 URL: https://issues.jboss.org/browse/WFLY-5391
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> When having defined default access logging (just changing {{extended}} attribute to {{false}}), instead of logging according to common pattern (the default pattern), only the word "common" is logged per each request.
> Marking as critical as this is behaviour with default access-log configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:41:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Wed, 23 Sep 2015 08:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4237) Disabling weld in wildfly
 strangely degrade JSF performance
In-Reply-To: <JIRA.12560710.1420986147000@Atlassian.JIRA>
References: <JIRA.12560710.1420986147000@Atlassian.JIRA>
	<JIRA.12560710.1420986147000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560710.1420986147000.7155.1443012060482@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned WFLY-4237:
----------------------------------------

    Assignee: Dmitrii Tikhomirov


> Disabling weld in wildfly strangely degrade JSF performance
> -----------------------------------------------------------
>
>                 Key: WFLY-4237
>                 URL: https://issues.jboss.org/browse/WFLY-4237
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.2.0.Final
>         Environment: Windows 7 64 bit,
> Oracle JDK 1.7.60 64bit,
> Wildfly 8.2.0.Final
> JSF 2.2
>            Reporter: Mostafa Abdelkhalek
>            Assignee: Dmitrii Tikhomirov
>         Attachments: weld_disabled.png, weld_enabled.png
>
>
> The ajax response time dramatically increases by increasing the number of JSF components when weld is disabled.
> This doesn't make sense and I have no idea why does it occur
> *WELD ENABLED*
> !weld_enabled.png|thumbnail!
> *WELD DISABLED*
> !weld_disabled.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:41:00 2015
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Wed, 23 Sep 2015 08:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-248) Constant pool index 268 is
	invalid
In-Reply-To: <JIRA.12577796.1436778937000@Atlassian.JIRA>
References: <JIRA.12577796.1436778937000@Atlassian.JIRA>
	<JIRA.12577796.1436778937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577796.1436778937000.7162.1443012060643@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111656#comment-13111656 ] 

Shigeru Chiba commented on JASSIST-248:
---------------------------------------

This might be a bug of Javassist.  Let me do further investigation.
Of course, ignoring default methods is a possible workaround.

> Constant pool index 268 is invalid
> ----------------------------------
>
>                 Key: JASSIST-248
>                 URL: https://issues.jboss.org/browse/JASSIST-248
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.19.0-GA
>            Reporter: Laurent Pellegrino
>            Assignee: Shigeru Chiba
>              Labels: regression
>         Attachments: _StubLinkedList.class
>
>
> We are using Javassist for one of our open source projects since about 10 years. Recently, I have tried to upgrade to version 3.19 and 3.20. Unfortunately, with both versions, generated byte code seems to cause errors with the JVM.
> Below is the output:
> {code}
> Exception in thread "RestartDownNodesPolicy node status check" java.lang.VerifyError: Illegal type at constant pool entry 268 in class pa.stub.java.util._StubLinkedList
> Exception Details:
>   Location:
>     pa/stub/java/util/_StubLinkedList.replaceAll(Ljava/util/function/UnaryOperator;)V @43: invokespecial
>   Reason:
>     Constant pool index 268 is invalid
>   Bytecode:
>     0x0000000: 2ab4 00cc 9900 252a b400 0db2 002c 100b
>     0x0000010: 32c0 0028 04bd 00ce 5903 2b53 b200 26b8
>     0x0000020: 00d7 b900 dd02 0057 b12a 2bb7 010c b1  
>   Stackmap Table:
>     same_frame(@41)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:264)
> 	at org.objectweb.proactive.core.mop.MOP.forName(MOP.java:155)
> 	at org.objectweb.proactive.core.mop.MOP.findStubConstructor(MOP.java:649)
> 	at org.objectweb.proactive.core.mop.MOP.createStubObject(MOP.java:822)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:338)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:196)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reifyAsAsynchronous(AbstractBodyProxy.java:277)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.invokeOnBody(AbstractBodyProxy.java:154)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reify(AbstractBodyProxy.java:123)
> 	at pa.stub.org.ow2.proactive.resourcemanager.nodesource._StubNodeSource.getDownNodes(_StubNodeSource.java)
> 	at org.ow2.proactive.resourcemanager.nodesource.policy.RestartDownNodesPolicy$1.run(RestartDownNodesPolicy.java:92)
> 	at java.util.TimerThread.mainLoop(Timer.java:555)
> 	at java.util.TimerThread.run(Timer.java:505)
> {code}
> The issue seems related to default methods introduced in Java 8. Perhaps its not an issue with Javassist but to be honest I don't understand the exception.  However, I have noticed that using Javassist in version 3.18.2 solves the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:47:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Sep 2015 08:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5392) Repeated Failure of
 EarPackagedMultiRarDeploymentTestCase
In-Reply-To: <JIRA.12585772.1443012363000@Atlassian.JIRA>
References: <JIRA.12585772.1443012363000@Atlassian.JIRA>
	<JIRA.12585772.1443012363033@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585772.1443012363000.7192.1443012420559@Atlassian.JIRA>

Darran Lofthouse created WFLY-5392:
--------------------------------------

             Summary: Repeated Failure of EarPackagedMultiRarDeploymentTestCase 
                 Key: WFLY-5392
                 URL: https://issues.jboss.org/browse/WFLY-5392
             Project: WildFly
          Issue Type: Bug
          Components: JCA
            Reporter: Darran Lofthouse
            Assignee: Tomaz Cerar
             Fix For: 10.0.0.CR2


The test is regularly failing, it could make it a candidate to be ignored but it does seem to stem from a NPE within the subsystem so maybe a fix is required: -

{noformat}
Caused by: java.lang.Exception: {"WFLYCTL0080: Failed services" => {"jboss.ra.deployer.\"ear_packaged.ear#ear_packaged2.rar\".jboss.ironjacamar.resource" => "org.jboss.msc.service.StartException in service jboss.ra.deployer.\"ear_packaged.ear#ear_packaged2.rar\".jboss.ironjacamar.resource: Failed to start service
    Caused by: java.lang.NullPointerException"}}
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
    at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:58:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 23 Sep 2015 08:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5392) Repeated Failure of
 EarPackagedMultiRarDeploymentTestCase
In-Reply-To: <JIRA.12585772.1443012363000@Atlassian.JIRA>
References: <JIRA.12585772.1443012363000@Atlassian.JIRA>
	<JIRA.12585772.1443012363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585772.1443012363000.7242.1443013080268@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-5392:
------------------------------
    Description: 
The test is regularly failing, it could make it a candidate to be ignored but it does seem to stem from a NPE within the subsystem so maybe a fix is required: -

{noformat}
13:36:23,229 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: org.jboss.msc.service.StartException in service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: 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.NullPointerException
    at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.start(IronJacamarActivationResourceService.java:196)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
{noformat}


  was:
The test is regularly failing, it could make it a candidate to be ignored but it does seem to stem from a NPE within the subsystem so maybe a fix is required: -

{noformat}
Caused by: java.lang.Exception: {"WFLYCTL0080: Failed services" => {"jboss.ra.deployer.\"ear_packaged.ear#ear_packaged2.rar\".jboss.ironjacamar.resource" => "org.jboss.msc.service.StartException in service jboss.ra.deployer.\"ear_packaged.ear#ear_packaged2.rar\".jboss.ironjacamar.resource: Failed to start service
    Caused by: java.lang.NullPointerException"}}
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
    at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
{noformat}




> Repeated Failure of EarPackagedMultiRarDeploymentTestCase 
> ----------------------------------------------------------
>
>                 Key: WFLY-5392
>                 URL: https://issues.jboss.org/browse/WFLY-5392
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR2
>
>
> The test is regularly failing, it could make it a candidate to be ignored but it does seem to stem from a NPE within the subsystem so maybe a fix is required: -
> {noformat}
> 13:36:23,229 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: org.jboss.msc.service.StartException in service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: 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.NullPointerException
>     at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.start(IronJacamarActivationResourceService.java:196)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 08:59:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Wed, 23 Sep 2015 08:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.7246.1443013140112@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111669#comment-13111669 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

Paul,

That join_timeout does not work in TCPPING.  I had already tried that when I first noticed the deprecated messages.  When I added the join_timeout to TCPPING there were exceptions in the server.log.  It did not recognize join_timeout as a property for TCPPING.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 09:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Sep 2015 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-293) Add file based auth to http
 management interface
In-Reply-To: <JIRA.12487616.1363783129000@Atlassian.JIRA>
References: <JIRA.12487616.1363783129000@Atlassian.JIRA>
	<JIRA.12487616.1363783129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487616.1363783129000.7354.1443014340306@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFCORE-327 to ELY-293:
---------------------------------------------

        Project: WildFly Elytron  (was: WildFly Core)
            Key: ELY-293  (was: WFCORE-327)
    Component/s: HTTP
                     (was: Domain Management)


> Add file based auth to http management interface
> ------------------------------------------------
>
>                 Key: ELY-293
>                 URL: https://issues.jboss.org/browse/ELY-293
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Max Rydahl Andersen
>            Assignee: Darran Lofthouse
>
> usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 09:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Sep 2015 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-293) Add file based auth to http
 management interface
In-Reply-To: <JIRA.12487616.1363783129000@Atlassian.JIRA>
References: <JIRA.12487616.1363783129000@Atlassian.JIRA>
	<JIRA.12487616.1363783129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487616.1363783129000.7359.1443014340406@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111679#comment-13111679 ] 

Darran Lofthouse commented on ELY-293:
--------------------------------------

At the moment if we do this it is more likely to be an Elytron authentication mechanism.

> Add file based auth to http management interface
> ------------------------------------------------
>
>                 Key: ELY-293
>                 URL: https://issues.jboss.org/browse/ELY-293
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Max Rydahl Andersen
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha1
>
>
> usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 09:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Sep 2015 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-293) Add file based auth to http
 management interface
In-Reply-To: <JIRA.12487616.1363783129000@Atlassian.JIRA>
References: <JIRA.12487616.1363783129000@Atlassian.JIRA>
	<JIRA.12487616.1363783129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487616.1363783129000.7364.1443014340494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-293:
---------------------------------
    Fix Version/s: 1.1.0.Alpha1


> Add file based auth to http management interface
> ------------------------------------------------
>
>                 Key: ELY-293
>                 URL: https://issues.jboss.org/browse/ELY-293
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Max Rydahl Andersen
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha1
>
>
> usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 09:20:00 2015
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 23 Sep 2015 09:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4959) Log INFO message when a
 security manager is activated
In-Reply-To: <JIRA.12578435.1437138658000@Atlassian.JIRA>
References: <JIRA.12578435.1437138658000@Atlassian.JIRA>
	<JIRA.12578435.1437138658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578435.1437138658000.7374.1443014400551@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111681#comment-13111681 ] 

Ivo Studensky commented on WFLY-4959:
-------------------------------------

I see what you mean. Such a log message would miss internalization which might be an issue.

> Log INFO message when a security manager is activated
> -----------------------------------------------------
>
>                 Key: WFLY-4959
>                 URL: https://issues.jboss.org/browse/WFLY-4959
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>
> When the server is started with security manager enabled, a message with this information should be logged. IMO the {{INFO}} log-level is the best option here.
> [~dmlloyd] says in [WFLY-403|https://issues.jboss.org/browse/WFLY-403?focusedCommentId=12755871&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12755871]:
> ??When a security manager is activated (whether by admin or at boot), a log message should announce that a security manager is now in force.??



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 09:39:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Sep 2015 09:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-499) System properties are broken
 in domain mode
In-Reply-To: <JIRA.12560803.1421114086000@Atlassian.JIRA>
References: <JIRA.12560803.1421114086000@Atlassian.JIRA>
	<JIRA.12560803.1421114086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560803.1421114086000.7481.1443015540608@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111695#comment-13111695 ] 

RH Bugzilla Integration commented on WFCORE-499:
------------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 1257301|https://bugzilla.redhat.com/show_bug.cgi?id=1257301] from ON_QA to VERIFIED

> System properties are broken in domain mode
> -------------------------------------------
>
>                 Key: WFCORE-499
>                 URL: https://issues.jboss.org/browse/WFCORE-499
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Alpha15
>            Reporter: Stuart Douglas
>            Assignee: ehsavoie Hugonnet
>             Fix For: 1.0.0.Alpha17
>
>
> There seems to be some weirdness in how system properties are being propagated to domain mode servers, and in many cases they are not being applied. 
> This appears to be an issue with the boot time handling of system properties.
> The only way I could get the property to be applied was to start the server first, then add the property using boot-time=false, although even in this case the property will disappear if the domain is restarted or the server is reloaded. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 09:42:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7509.1443015720359@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka reopened WFLY-5100:
------------------------------------


Working either with WFLY 10.CR1 or the latest compiled version from upstream I still hit this issue. After adding attribut `<use-journal-store/>` (either directly to xml or via cli) the server starts with several errors.

{code}
2015-09-23 15:39:13,922 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.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.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:182)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243)
	at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
	... 5 more

2015-09-23 15:39:14,212 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/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules,/home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/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

2015-09-23 15:39:14,227 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) WFLYDS0013: Started FileSystemDeploymentService for directory /home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/standalone/deployments
2015-09-23 15:39:14,289 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
	at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:269)
	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.RuntimeException: java.net.BindException: Address already in use
	at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:160)
	at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:235)
	... 5 more
Caused by: java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:182)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243)
	at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:147)
	... 6 more

2015-09-23 15:39:14,293 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("core-service" => "management"),
    ("management-interface" => "http-interface")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.serverManagement.controller.management.http" => "org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
    Caused by: java.lang.RuntimeException: java.net.BindException: Address already in use
    Caused by: java.net.BindException: Address already in use"},
    "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
        "Services that were unable to start:" => ["jboss.serverManagement.controller.management.http.shutdown"],
        "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
    }
}
2015-09-23 15:39:14,295 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("context-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.context.service.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,299 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-thread-factory" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.threadfactory.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,300 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-executor-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.executor.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,305 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-scheduled-executor-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.scheduledexecutor.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,307 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "datasources"),
    ("data-source" => "ExampleDS")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["org.wildfly.data-source.ExampleDS"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,308 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "security")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.security.transaction-manager-locator"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,310 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.ws.config"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,312 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "jca")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.connector.transactionintegration",
        "jboss.rarepository"
    ],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,314 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "jca"),
    ("bootstrap-context" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.connector.bootstrapcontext.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,315 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "datasources"),
    ("data-source" => "ExampleDS")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "org.wildfly.data-source.ExampleDS",
        "jboss.data-source.reference-factory.ExampleDS",
        "jboss.naming.context.java.jboss.datasources.ExampleDS",
        "org.wildfly.data-source.ExampleDS"
    ],
    "Services that may be the cause:" => [
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector",
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
    ]
}}
2015-09-23 15:39:14,316 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "jca"),
    ("cached-connection-manager" => "cached-connection-manager")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.cached-connection-manager"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,318 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "undertow"),
    ("server" => "default-server"),
    ("http-listener" => "default")
]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
    Caused by: java.net.BindException: Address already in use"}}
2015-09-23 15:39:14,319 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/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules,/home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules/system/layers/base))]"},
    "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
        "Services that were unable to start:" => [
            "jboss.concurrent.ee.tsp",
            "jboss.naming.context.java.TransactionManager",
            "jboss.naming.context.java.jboss.TransactionManager",
            "jboss.naming.context.java.jboss.TransactionSynchronizationRegistry",
            "jboss.naming.context.java.jboss.UserTransaction",
            "jboss.txn.ArjunaTransactionManager",
            "jboss.txn.TransactionManager",
            "jboss.txn.TransactionSynchronizationRegistry",
            "jboss.txn.UserTransaction"
        ],
        "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
    }
}
2015-09-23 15:39:14,323 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.ejb.default-local-ejb-receiver-service",
        "jboss.ejb.tx-recovery-service",
        "jboss.ejb.utilities",
        "jboss.ejb3.ejbClientContext.default",
        "jboss.ejb3.localEjbReceiver.value"
    ],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,325 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "timer-service"),
    ("file-data-store" => "default-file-store")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.ejb3.timerService.timerPersistence.default-file-store"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,327 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "remote")
]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb3.connector is missing [jboss.remoting.remotingConnectorInfoService.http-remoting-connector]"]}
2015-09-23 15:39:14,395 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0184:    New missing/unsatisfied dependencies:
      service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service jboss.ejb3.connector] 
WFLYCTL0186:   Services which failed to start:      service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
      service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
      service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service

2015-09-23 15:39:14,505 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0063: Http management interface is not enabled
2015-09-23 15:39:14,505 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0054: Admin console is not enabled
2015-09-23 15:39:14,506 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.0.0.CR2-SNAPSHOT (WildFly Core 2.0.0.CR4) started (with errors) in 3594ms - Started 163 of 482 services (34 services failed or missing dependencies, 315 services are lazy, passive or on-demand)
2015-09-23 15:40:37,179 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
2015-09-23 15:40:37,205 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping
2015-09-23 15:40:37,207 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
2015-09-23 15:40:37,213 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.3.0.CR2 stopping
2015-09-23 15:40:37,220 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR2-SNAPSHOT (WildFly Core 2.0.0.CR4) stopped in 17ms
{code}

> Server does not start when transaction subsystem configures hornetq/activemq 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
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>             Fix For: 10.0.0.Beta2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:42:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7515.1443015720579@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5100:
-----------------------------------
    Priority: Blocker  (was: Major)


> Server does not start when transaction subsystem configures hornetq/activemq 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
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Beta2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:43:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7525.1443015780728@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111701#comment-13111701 ] 

Ond?ej Chaloupka commented on WFLY-5100:
----------------------------------------

Changing the priority to blocker as it's important feature of jboss transaction subsystem which were supported in older EAP release.

> Server does not start when transaction subsystem configures hornetq/activemq 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
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Beta2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:44:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7533.1443015840471@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111698#comment-13111698 ] 

Ond?ej Chaloupka edited comment on WFLY-5100 at 9/23/15 9:43 AM:
-----------------------------------------------------------------

Working either with WFLY 10.CR1 or the latest compiled version from upstream I still hit this issue. After adding attribut {{<use-journal-store/>}} (either directly to xml or via cli) the server starts with several errors.

{code}
2015-09-23 15:39:13,922 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.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.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:182)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243)
	at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
	... 5 more

2015-09-23 15:39:14,212 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/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules,/home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/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

2015-09-23 15:39:14,227 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) WFLYDS0013: Started FileSystemDeploymentService for directory /home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/standalone/deployments
2015-09-23 15:39:14,289 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
	at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:269)
	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.RuntimeException: java.net.BindException: Address already in use
	at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:160)
	at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:235)
	... 5 more
Caused by: java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:182)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243)
	at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:147)
	... 6 more

2015-09-23 15:39:14,293 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("core-service" => "management"),
    ("management-interface" => "http-interface")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.serverManagement.controller.management.http" => "org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
    Caused by: java.lang.RuntimeException: java.net.BindException: Address already in use
    Caused by: java.net.BindException: Address already in use"},
    "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
        "Services that were unable to start:" => ["jboss.serverManagement.controller.management.http.shutdown"],
        "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
    }
}
2015-09-23 15:39:14,295 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("context-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.context.service.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,299 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-thread-factory" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.threadfactory.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,300 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-executor-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.executor.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,305 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-scheduled-executor-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.scheduledexecutor.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,307 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "datasources"),
    ("data-source" => "ExampleDS")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["org.wildfly.data-source.ExampleDS"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,308 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "security")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.security.transaction-manager-locator"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,310 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.ws.config"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,312 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "jca")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.connector.transactionintegration",
        "jboss.rarepository"
    ],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,314 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "jca"),
    ("bootstrap-context" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.connector.bootstrapcontext.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,315 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "datasources"),
    ("data-source" => "ExampleDS")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "org.wildfly.data-source.ExampleDS",
        "jboss.data-source.reference-factory.ExampleDS",
        "jboss.naming.context.java.jboss.datasources.ExampleDS",
        "org.wildfly.data-source.ExampleDS"
    ],
    "Services that may be the cause:" => [
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector",
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
    ]
}}
2015-09-23 15:39:14,316 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "jca"),
    ("cached-connection-manager" => "cached-connection-manager")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.cached-connection-manager"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,318 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "undertow"),
    ("server" => "default-server"),
    ("http-listener" => "default")
]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
    Caused by: java.net.BindException: Address already in use"}}
2015-09-23 15:39:14,319 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/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules,/home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules/system/layers/base))]"},
    "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
        "Services that were unable to start:" => [
            "jboss.concurrent.ee.tsp",
            "jboss.naming.context.java.TransactionManager",
            "jboss.naming.context.java.jboss.TransactionManager",
            "jboss.naming.context.java.jboss.TransactionSynchronizationRegistry",
            "jboss.naming.context.java.jboss.UserTransaction",
            "jboss.txn.ArjunaTransactionManager",
            "jboss.txn.TransactionManager",
            "jboss.txn.TransactionSynchronizationRegistry",
            "jboss.txn.UserTransaction"
        ],
        "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
    }
}
2015-09-23 15:39:14,323 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.ejb.default-local-ejb-receiver-service",
        "jboss.ejb.tx-recovery-service",
        "jboss.ejb.utilities",
        "jboss.ejb3.ejbClientContext.default",
        "jboss.ejb3.localEjbReceiver.value"
    ],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,325 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "timer-service"),
    ("file-data-store" => "default-file-store")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.ejb3.timerService.timerPersistence.default-file-store"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,327 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "remote")
]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb3.connector is missing [jboss.remoting.remotingConnectorInfoService.http-remoting-connector]"]}
2015-09-23 15:39:14,395 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0184:    New missing/unsatisfied dependencies:
      service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service jboss.ejb3.connector] 
WFLYCTL0186:   Services which failed to start:      service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
      service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
      service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service

2015-09-23 15:39:14,505 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0063: Http management interface is not enabled
2015-09-23 15:39:14,505 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0054: Admin console is not enabled
2015-09-23 15:39:14,506 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.0.0.CR2-SNAPSHOT (WildFly Core 2.0.0.CR4) started (with errors) in 3594ms - Started 163 of 482 services (34 services failed or missing dependencies, 315 services are lazy, passive or on-demand)
2015-09-23 15:40:37,179 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
2015-09-23 15:40:37,205 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping
2015-09-23 15:40:37,207 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
2015-09-23 15:40:37,213 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.3.0.CR2 stopping
2015-09-23 15:40:37,220 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR2-SNAPSHOT (WildFly Core 2.0.0.CR4) stopped in 17ms
{code}


was (Author: ochaloup):
Working either with WFLY 10.CR1 or the latest compiled version from upstream I still hit this issue. After adding attribut `<use-journal-store/>` (either directly to xml or via cli) the server starts with several errors.

{code}
2015-09-23 15:39:13,922 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.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.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:182)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243)
	at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
	... 5 more

2015-09-23 15:39:14,212 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/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules,/home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/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

2015-09-23 15:39:14,227 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) WFLYDS0013: Started FileSystemDeploymentService for directory /home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/standalone/deployments
2015-09-23 15:39:14,289 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
	at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:269)
	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.RuntimeException: java.net.BindException: Address already in use
	at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:160)
	at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:235)
	... 5 more
Caused by: java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:182)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243)
	at org.jboss.as.domain.http.server.ManagementHttpServer.start(ManagementHttpServer.java:147)
	... 6 more

2015-09-23 15:39:14,293 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("core-service" => "management"),
    ("management-interface" => "http-interface")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.serverManagement.controller.management.http" => "org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
    Caused by: java.lang.RuntimeException: java.net.BindException: Address already in use
    Caused by: java.net.BindException: Address already in use"},
    "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
        "Services that were unable to start:" => ["jboss.serverManagement.controller.management.http.shutdown"],
        "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
    }
}
2015-09-23 15:39:14,295 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("context-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.context.service.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,299 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-thread-factory" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.threadfactory.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,300 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-executor-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.executor.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,305 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ee"),
    ("managed-scheduled-executor-service" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.concurrent.ee.scheduledexecutor.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,307 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "datasources"),
    ("data-source" => "ExampleDS")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["org.wildfly.data-source.ExampleDS"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,308 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "security")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.security.transaction-manager-locator"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,310 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.ws.config"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,312 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "jca")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.connector.transactionintegration",
        "jboss.rarepository"
    ],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,314 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "jca"),
    ("bootstrap-context" => "default")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.connector.bootstrapcontext.default"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,315 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "datasources"),
    ("data-source" => "ExampleDS")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "org.wildfly.data-source.ExampleDS",
        "jboss.data-source.reference-factory.ExampleDS",
        "jboss.naming.context.java.jboss.datasources.ExampleDS",
        "org.wildfly.data-source.ExampleDS"
    ],
    "Services that may be the cause:" => [
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector",
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
    ]
}}
2015-09-23 15:39:14,316 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "jca"),
    ("cached-connection-manager" => "cached-connection-manager")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.cached-connection-manager"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,318 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "undertow"),
    ("server" => "default-server"),
    ("http-listener" => "default")
]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
    Caused by: java.net.BindException: Address already in use"}}
2015-09-23 15:39:14,319 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/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules,/home/ochaloup/jboss/wildfly/dist/target/wildfly-10.0.0.CR2-SNAPSHOT/modules/system/layers/base))]"},
    "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
        "Services that were unable to start:" => [
            "jboss.concurrent.ee.tsp",
            "jboss.naming.context.java.TransactionManager",
            "jboss.naming.context.java.jboss.TransactionManager",
            "jboss.naming.context.java.jboss.TransactionSynchronizationRegistry",
            "jboss.naming.context.java.jboss.UserTransaction",
            "jboss.txn.ArjunaTransactionManager",
            "jboss.txn.TransactionManager",
            "jboss.txn.TransactionSynchronizationRegistry",
            "jboss.txn.UserTransaction"
        ],
        "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
    }
}
2015-09-23 15:39:14,323 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => [
        "jboss.ejb.default-local-ejb-receiver-service",
        "jboss.ejb.tx-recovery-service",
        "jboss.ejb.utilities",
        "jboss.ejb3.ejbClientContext.default",
        "jboss.ejb3.localEjbReceiver.value"
    ],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,325 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "timer-service"),
    ("file-data-store" => "default-file-store")
]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.ejb3.timerService.timerPersistence.default-file-store"],
    "Services that may be the cause:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"]
}}
2015-09-23 15:39:14,327 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "remote")
]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb3.connector is missing [jboss.remoting.remotingConnectorInfoService.http-remoting-connector]"]}
2015-09-23 15:39:14,395 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0184:    New missing/unsatisfied dependencies:
      service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service jboss.ejb3.connector] 
WFLYCTL0186:   Services which failed to start:      service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
      service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: WFLYSRV0083: Failed to start the http-interface service
      service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service

2015-09-23 15:39:14,505 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0063: Http management interface is not enabled
2015-09-23 15:39:14,505 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0054: Admin console is not enabled
2015-09-23 15:39:14,506 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.0.0.CR2-SNAPSHOT (WildFly Core 2.0.0.CR4) started (with errors) in 3594ms - Started 163 of 482 services (34 services failed or missing dependencies, 315 services are lazy, passive or on-demand)
2015-09-23 15:40:37,179 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
2015-09-23 15:40:37,205 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0019: Host default-host stopping
2015-09-23 15:40:37,207 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
2015-09-23 15:40:37,213 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.3.0.CR2 stopping
2015-09-23 15:40:37,220 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Full 10.0.0.CR2-SNAPSHOT (WildFly Core 2.0.0.CR4) stopped in 17ms
{code}

> Server does not start when transaction subsystem configures hornetq/activemq 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
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Beta2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:52:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 23 Sep 2015 09:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7562.1443016320348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5100:
--------------------------------
    Fix Version/s: 10.0.0.CR2
                       (was: 10.0.0.Beta2)


> Server does not start when transaction subsystem configures hornetq/activemq 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
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:52:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 23 Sep 2015 09:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7566.1443016320425@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5100:
--------------------------------
    Affects Version/s: 10.0.0.Beta2


> Server does not start when transaction subsystem configures hornetq/activemq 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
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:54:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 23 Sep 2015 09:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7580.1443016440251@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111709#comment-13111709 ] 

Tom Jenkinson commented on WFLY-5100:
-------------------------------------

Hi Ondra,

Please can you update the description as I think the instructions relating to use-hornetq-store may be out of date?

Also, if possible please can you attach a standalone.xml so I can be sure we are looking at the same thing?

Many thanks!
Tom

> Server does not start when transaction subsystem configures hornetq/activemq 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
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:54:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5393) Using deprecated attribute
 use-hornetq-store in CLI does not have any effect being set
In-Reply-To: <JIRA.12585786.1443016438000@Atlassian.JIRA>
References: <JIRA.12585786.1443016438000@Atlassian.JIRA>
	<JIRA.12585786.1443016438955@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585786.1443016438000.7589.1443016440479@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5393:
--------------------------------------

             Summary: Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
                 Key: WFLY-5393
                 URL: https://issues.jboss.org/browse/WFLY-5393
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
            Reporter: Ond?ej Chaloupka
            Assignee: Tom Jenkinson


Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality.

I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used.

I would think that when one of the attribute is set then the other one should present the same settings.

{code}
/subsystem=transactions:read-attribute(name=use-hornetq-store)
{
    "outcome" => "success",
    "result" => false
}
/subsystem=transactions:read-attribute(name=use-journal-store)
{
    "outcome" => "success",
    "result" => false
}
/subsystem=transactions:write-attribute(name=use-journal-store, value=true)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-restart" => true,
        "process-state" => "restart-required"
    }
}

:shutdown(restart=true)
{"outcome" => "success"}

/subsystem=transactions:read-attribute(name=use-journal-store)
{
    "outcome" => "success",
    "result" => true
}
 /subsystem=transactions:read-attribute(name=use-hornetq-store)
{
    "outcome" => "success",
    "result" => false
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:55:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5393) Using deprecated attribute
 use-hornetq-store in CLI does not have any effect being set
In-Reply-To: <JIRA.12585786.1443016438000@Atlassian.JIRA>
References: <JIRA.12585786.1443016438000@Atlassian.JIRA>
	<JIRA.12585786.1443016438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585786.1443016438000.7592.1443016500222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5393:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5393
>                 URL: https://issues.jboss.org/browse/WFLY-5393
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tom Jenkinson
>
> Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality.
> I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used.
> I would think that when one of the attribute is set then the other one should present the same settings.
> {code}
> /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-restart" => true,
>         "process-state" => "restart-required"
>     }
> }
> :shutdown(restart=true)
> {"outcome" => "success"}
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
>     "outcome" => "success",
>     "result" => true
> }
>  /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:55:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5393) Using deprecated attribute
 use-hornetq-store in CLI does not have any effect being set
In-Reply-To: <JIRA.12585786.1443016438000@Atlassian.JIRA>
References: <JIRA.12585786.1443016438000@Atlassian.JIRA>
	<JIRA.12585786.1443016438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585786.1443016438000.7596.1443016500334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka reassigned WFLY-5393:
--------------------------------------

    Assignee: Amos Feng  (was: Tom Jenkinson)


> Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5393
>                 URL: https://issues.jboss.org/browse/WFLY-5393
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>
> Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality.
> I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used.
> I would think that when one of the attribute is set then the other one should present the same settings.
> {code}
> /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-restart" => true,
>         "process-state" => "restart-required"
>     }
> }
> :shutdown(restart=true)
> {"outcome" => "success"}
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
>     "outcome" => "success",
>     "result" => true
> }
>  /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:55:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5393) Using deprecated attribute
 use-hornetq-store in CLI does not have any effect being set
In-Reply-To: <JIRA.12585786.1443016438000@Atlassian.JIRA>
References: <JIRA.12585786.1443016438000@Atlassian.JIRA>
	<JIRA.12585786.1443016438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585786.1443016438000.7599.1443016500389@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5393:
-----------------------------------
    Steps to Reproduce: 
Use {{jboss-cli.sh}} to set {{/subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)}} does not have any effect.



> Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5393
>                 URL: https://issues.jboss.org/browse/WFLY-5393
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Amos Feng
>
> Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality.
> I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used.
> I would think that when one of the attribute is set then the other one should present the same settings.
> {code}
> /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-restart" => true,
>         "process-state" => "restart-required"
>     }
> }
> :shutdown(restart=true)
> {"outcome" => "success"}
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
>     "outcome" => "success",
>     "result" => true
> }
>  /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:58:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7614.1443016680414@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5100:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> Server does not start when transaction subsystem configures hornetq/activemq 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-hornetq-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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:58:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures hornetq/activemq 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.7618.1443016680597@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5100:
-----------------------------------
    Description: 
Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].

[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

  was:
Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].

[1]
{code}
/subsystem=transactions:write-attribute(name=use-hornetq-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



> Server does not start when transaction subsystem configures hornetq/activemq 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 09:58:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 09:58:00 -0400 (EDT)
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.7623.1443016680760@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5100:
-----------------------------------
    Summary: Server does not start when transaction subsystem configures journal object store  (was: Server does not start when transaction subsystem configures hornetq/activemq object store)


> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].
> [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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 10:00:01 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 10:00:01 -0400 (EDT)
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.7634.1443016801158@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5100:
-----------------------------------
    Description: 
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

  was:
Currently when object store is configured to use journal to save the txn log the server won't start. For DR8 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].

[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



> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>
> 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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 10:03:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 10:03:00 -0400 (EDT)
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.7650.1443016980178@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5100:
-----------------------------------
    Attachment: standalone.xml


I've taken the {{standalone.xml}} from WFLY built a few whiles ago from github upstream.

The only change that was done, in comparision with supplied configuratioin, was adding element {{use-journal-store}} under transaction subsystem. I have the same experience when doing so via cli {{/subsystem=transactions:write-attribute(name=use-journal-store, value=true)}}

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 10:05:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 10:05:00 -0400 (EDT)
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.7656.1443017100151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111716#comment-13111716 ] 

Ond?ej Chaloupka commented on WFLY-5100:
----------------------------------------

Hi Tom,

I've attached the config file. I've proceeded with configuration in the same way how the {{use-hornetq-store}} worked in EAP6. Maybe I skip some step now?

Thanks for checking this

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 10:05:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 23 Sep 2015 10:05:00 -0400 (EDT)
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.7660.1443017100316@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111716#comment-13111716 ] 

Ond?ej Chaloupka edited comment on WFLY-5100 at 9/23/15 10:04 AM:
------------------------------------------------------------------

Hi Tom,

I've attached the config file. I've proceeded with configuration in the same way how the {{use-hornetq-store}} worked in EAP6. Maybe I've skipped some step now?

Thanks for checking this


was (Author: ochaloup):
Hi Tom,

I've attached the config file. I've proceeded with configuration in the same way how the {{use-hornetq-store}} worked in EAP6. Maybe I skip some step now?

Thanks for checking this

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 23 10:12:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Wed, 23 Sep 2015 10:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5394) Netty acceptor is ignored in
 configuration and not opened
In-Reply-To: <JIRA.12585794.1443017471000@Atlassian.JIRA>
References: <JIRA.12585794.1443017471000@Atlassian.JIRA>
	<JIRA.12585794.1443017471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585794.1443017471000.7721.1443017520594@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak moved JBEAP-1138 to WFLY-5394:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5394  (was: JBEAP-1138)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: JMS
                           (was: JMS)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR10 (Alpha))


> Netty acceptor is ignored in configuration and not opened 
> ----------------------------------------------------------
>
>                 Key: WFLY-5394
>                 URL: https://issues.jboss.org/browse/WFLY-5394
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Critical
>
> If netty acceptor is configured then port is not opened:
> {code}
> <acceptor name="netty" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory" socket-binding="messaging"/>
> {code}
> after server is started. Setting higher priority because it's core functionality.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 10:32:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 23 Sep 2015 10:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5394) Netty acceptor is ignored in
 configuration and not opened
In-Reply-To: <JIRA.12585794.1443017471000@Atlassian.JIRA>
References: <JIRA.12585794.1443017471000@Atlassian.JIRA>
	<JIRA.12585794.1443017471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585794.1443017471000.7871.1443018720732@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5394:
------------------------------
    Priority: Minor  (was: Critical)


> Netty acceptor is ignored in configuration and not opened 
> ----------------------------------------------------------
>
>                 Key: WFLY-5394
>                 URL: https://issues.jboss.org/browse/WFLY-5394
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> If netty acceptor is configured then port is not opened:
> {code}
> <acceptor name="netty" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory" socket-binding="messaging"/>
> {code}
> after server is started. Setting higher priority because it's core functionality.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 10:33:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Sep 2015 10:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.7877.1443018780200@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111742#comment-13111742 ] 

Paul Ferraro commented on WFLY-5358:
------------------------------------

[~czacharym] As indicated in the log message, join_timeout is a property of GMS, not TCPPING.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 10:34:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 23 Sep 2015 10:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5394) Netty acceptor is ignored in
 configuration and not opened
In-Reply-To: <JIRA.12585794.1443017471000@Atlassian.JIRA>
References: <JIRA.12585794.1443017471000@Atlassian.JIRA>
	<JIRA.12585794.1443017471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585794.1443017471000.7880.1443018840161@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111743#comment-13111743 ] 

Jeff Mesnil commented on WFLY-5394:
-----------------------------------

This is not blocker. The right way to configure a Netty acceptor is to use a remote-acceptor.

We are moving away from having class names in our configuration. Unless there is a compelling reason to use a generic acceptor, we should be avoided.

Having look at the attached configuration, I don't see the definition of the messaging socket-binding? Was it omitted on purpose?

> Netty acceptor is ignored in configuration and not opened 
> ----------------------------------------------------------
>
>                 Key: WFLY-5394
>                 URL: https://issues.jboss.org/browse/WFLY-5394
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> If netty acceptor is configured then port is not opened:
> {code}
> <acceptor name="netty" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory" socket-binding="messaging"/>
> {code}
> after server is started. Setting higher priority because it's core functionality.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 10:40:00 2015
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 23 Sep 2015 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5395) Search scope OBJECT_SCOPE
 does not work correctly for LdapExtLoginModule
In-Reply-To: <JIRA.12585800.1443019145000@Atlassian.JIRA>
References: <JIRA.12585800.1443019145000@Atlassian.JIRA>
	<JIRA.12585800.1443019145599@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585800.1443019145000.7894.1443019200598@Atlassian.JIRA>

Ondrej Lukas created WFLY-5395:
----------------------------------

             Summary: Search scope OBJECT_SCOPE does not work correctly for LdapExtLoginModule
                 Key: WFLY-5395
                 URL: https://issues.jboss.org/browse/WFLY-5395
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


LDAP authentication fails (HTTP 401 returned) when login module option searchScope=OBJECT_SCOPE is used.

This problem is caused by searching attributes for role DN which starts with comma - e.g. ",cn=JBossAdmin,ou=Roles,dc=jboss,dc=org".

You can reproduce it by following configuration:

Security domain:
{code:xml}
<security-domain name="ldap">
    <authentication>
        <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
            <module-option name="searchScope" value="OBJECT_SCOPE"/>
            <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
            <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
            <module-option name="roleAttributeIsDN" value="true"/>
            <module-option name="roleFilter" value="(member={1})"/>
            <module-option name="roleAttributeID" value="cn"/>
            <module-option name="rolesCtxDN" value="cn=JBossAdmin,ou=Roles,dc=jboss,dc=org"/>
            <module-option name="java.naming.security.authentication" value="simple"/>
            <module-option name="bindDN" value="uid=admin,ou=system"/>
            <module-option name="bindCredential" value="secret"/>
            <module-option name="baseCtxDN" value="ou=People,dc=jboss,dc=org"/>
            <module-option name="throwValidateError" value="true"/>
            <module-option name="baseFilter" value="(uid={0})"/>
            <module-option name="roleNameAttributeID" value="cn"/>
        </login-module>
    </authentication>
</security-domain>
{code}

LDIF for role:
{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=JBossAdmin,ou=Roles,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
cn: JBossAdmin
member: uid=jduke,ou=People,dc=jboss,dc=org
{code}

It seems the method LdapExtLoginModule.canonicalize() causes this problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 10:40:00 2015
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 23 Sep 2015 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5395) Search scope OBJECT_SCOPE
 does not work correctly for LdapExtLoginModule
In-Reply-To: <JIRA.12585800.1443019145000@Atlassian.JIRA>
References: <JIRA.12585800.1443019145000@Atlassian.JIRA>
	<JIRA.12585800.1443019145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585800.1443019145000.7899.1443019200756@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-5395:
-------------------------------
    Affects Version/s: 10.0.0.CR1


> Search scope OBJECT_SCOPE does not work correctly for LdapExtLoginModule
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5395
>                 URL: https://issues.jboss.org/browse/WFLY-5395
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> LDAP authentication fails (HTTP 401 returned) when login module option searchScope=OBJECT_SCOPE is used.
> This problem is caused by searching attributes for role DN which starts with comma - e.g. ",cn=JBossAdmin,ou=Roles,dc=jboss,dc=org".
> You can reproduce it by following configuration:
> Security domain:
> {code:xml}
> <security-domain name="ldap">
>     <authentication>
>         <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
>             <module-option name="searchScope" value="OBJECT_SCOPE"/>
>             <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
>             <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
>             <module-option name="roleAttributeIsDN" value="true"/>
>             <module-option name="roleFilter" value="(member={1})"/>
>             <module-option name="roleAttributeID" value="cn"/>
>             <module-option name="rolesCtxDN" value="cn=JBossAdmin,ou=Roles,dc=jboss,dc=org"/>
>             <module-option name="java.naming.security.authentication" value="simple"/>
>             <module-option name="bindDN" value="uid=admin,ou=system"/>
>             <module-option name="bindCredential" value="secret"/>
>             <module-option name="baseCtxDN" value="ou=People,dc=jboss,dc=org"/>
>             <module-option name="throwValidateError" value="true"/>
>             <module-option name="baseFilter" value="(uid={0})"/>
>             <module-option name="roleNameAttributeID" value="cn"/>
>         </login-module>
>     </authentication>
> </security-domain>
> {code}
> LDIF for role:
> {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=JBossAdmin,ou=Roles,dc=jboss,dc=org
> objectClass: top
> objectClass: groupOfNames
> cn: JBossAdmin
> member: uid=jduke,ou=People,dc=jboss,dc=org
> {code}
> It seems the method LdapExtLoginModule.canonicalize() causes this problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 10:40:00 2015
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 23 Sep 2015 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5396) Search scope OBJECT_SCOPE
 does not work correctly for AdvancedLdapLoginModule
In-Reply-To: <JIRA.12585801.1443019188000@Atlassian.JIRA>
References: <JIRA.12585801.1443019188000@Atlassian.JIRA>
	<JIRA.12585801.1443019188842@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585801.1443019188000.7904.1443019200888@Atlassian.JIRA>

Ondrej Lukas created WFLY-5396:
----------------------------------

             Summary: Search scope OBJECT_SCOPE does not work correctly for AdvancedLdapLoginModule
                 Key: WFLY-5396
                 URL: https://issues.jboss.org/browse/WFLY-5396
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


Search scope OBJECT_SCOPE does not work correctly for AdvancedLdapLoginModule

LDAP authentication fails (HTTP 401 returned) when login module option searchScope=OBJECT_SCOPE is used.

This problem is caused by searching attributes for role DN which starts with comma - e.g. ",cn=JBossAdmin,ou=Roles,dc=jboss,dc=org".

You can reproduce it by following configuration:

Security domain:
{code:xml}
<security-domain name="ldap">
    <authentication>
        <login-module code="AdvancedLdap" flag="required">
            <module-option name="bindDN" value="uid=admin,ou=system"/>
            <module-option name="bindCredential" value="secret"/>
            <module-option name="baseCtxDN" value="ou=People,dc=jboss,dc=org"/>
            <module-option name="searchScope" value="OBJECT_SCOPE"/>
            <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
            <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
            <module-option name="throwValidateError" value="true"/>
            <module-option name="baseFilter" value="(uid={0})"/>
            <module-option name="roleFilter" value="(member={1})"/>
            <module-option name="roleAttributeID" value="cn"/>
            <module-option name="rolesCtxDN" value="cn=JBossAdmin,ou=Roles,dc=jboss,dc=org"/>
            <module-option name="java.naming.security.authentication" value="simple"/>
        </login-module>
    </authentication>
</security-domain>
{code}

LDIF for role:
{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=JBossAdmin,ou=Roles,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
cn: JBossAdmin
member: uid=jduke,ou=People,dc=jboss,dc=org
{code}

It seems the method AdvancedLdapLoginModule.canonicalize() causes this problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 10:40:01 2015
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 23 Sep 2015 10:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5396) Search scope OBJECT_SCOPE
 does not work correctly for AdvancedLdapLoginModule
In-Reply-To: <JIRA.12585801.1443019188000@Atlassian.JIRA>
References: <JIRA.12585801.1443019188000@Atlassian.JIRA>
	<JIRA.12585801.1443019188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585801.1443019188000.7907.1443019201066@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-5396:
-------------------------------
    Affects Version/s: 10.0.0.CR1


> Search scope OBJECT_SCOPE does not work correctly for AdvancedLdapLoginModule
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-5396
>                 URL: https://issues.jboss.org/browse/WFLY-5396
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> Search scope OBJECT_SCOPE does not work correctly for AdvancedLdapLoginModule
> LDAP authentication fails (HTTP 401 returned) when login module option searchScope=OBJECT_SCOPE is used.
> This problem is caused by searching attributes for role DN which starts with comma - e.g. ",cn=JBossAdmin,ou=Roles,dc=jboss,dc=org".
> You can reproduce it by following configuration:
> Security domain:
> {code:xml}
> <security-domain name="ldap">
>     <authentication>
>         <login-module code="AdvancedLdap" flag="required">
>             <module-option name="bindDN" value="uid=admin,ou=system"/>
>             <module-option name="bindCredential" value="secret"/>
>             <module-option name="baseCtxDN" value="ou=People,dc=jboss,dc=org"/>
>             <module-option name="searchScope" value="OBJECT_SCOPE"/>
>             <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
>             <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
>             <module-option name="throwValidateError" value="true"/>
>             <module-option name="baseFilter" value="(uid={0})"/>
>             <module-option name="roleFilter" value="(member={1})"/>
>             <module-option name="roleAttributeID" value="cn"/>
>             <module-option name="rolesCtxDN" value="cn=JBossAdmin,ou=Roles,dc=jboss,dc=org"/>
>             <module-option name="java.naming.security.authentication" value="simple"/>
>         </login-module>
>     </authentication>
> </security-domain>
> {code}
> LDIF for role:
> {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=JBossAdmin,ou=Roles,dc=jboss,dc=org
> objectClass: top
> objectClass: groupOfNames
> cn: JBossAdmin
> member: uid=jduke,ou=People,dc=jboss,dc=org
> {code}
> It seems the method AdvancedLdapLoginModule.canonicalize() causes this problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 11:41:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 11:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.8220.1443022860194@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111780#comment-13111780 ] 

Heiko Braun commented on WFCORE-994:
------------------------------------

On a related note: Can you verify why the following query only returns a single element in the response?

{noformat}
/host=*/server-config=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
{noformat}

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 11:41:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 11:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.8225.1443022860361@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111780#comment-13111780 ] 

Heiko Braun edited comment on WFCORE-994 at 9/23/15 11:40 AM:
--------------------------------------------------------------

On a related note: Can you verify why the following query only returns a single element in the response?

{noformat}
/host=*/server-config=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
{noformat}

Looking at the '/host=*:read-resource-description()' case, I would assume that it also returns a list of host responses


was (Author: heiko.braun):
On a related note: Can you verify why the following query only returns a single element in the response?

{noformat}
/host=*/server-config=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
{noformat}

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 11:43:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.8230.1443022980202@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111781#comment-13111781 ] 

Heiko Braun commented on WFCORE-994:
------------------------------------

Can someone explain the difference between a) and b)?

a) 
{noformat}
[domain at localhost:9990 /] /host=*/server-config=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("host" => "master"),
            ("server-config" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            " capabilities" => [{
                "name" => "org.wildfly.domain.server-config",
                "dynamic" => true
            }],
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {
                "interface" => {"model-description" => undefined},
                "jvm" => {"model-description" => undefined},
                "path" => {"model-description" => undefined},
                "system-property" => {"model-description" => undefined}
            },
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "auto-start" => {
                            "read" => true,
                            "write" => true
                        },
                        "cpu-affinity" => {
                            "read" => true,
                            "write" => true
                        },
                        "group" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "priority" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-default-interface" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-group" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-port-offset" => {
                            "read" => true,
                            "write" => true
                        },
                        "status" => {
                            "read" => true,
                            "write" => true
                        },
                        "update-auto-start-with-server-status" => {
                            "read" => true,
                            "write" => true
                        }
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

{noformat}

b) 
{noformat}
[domain at localhost:9990 /] /host=*/server=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [
                ("host" => "master"),
                ("server" => "*")
            ],
            "outcome" => "success",
            "result" => {
                "description" => undefined,
                "attributes" => undefined,
                "operations" => undefined,
                "notifications" => undefined,
                "children" => {},
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "launch-type" => {
                                "read" => true,
                                "write" => true
                            },
                            "server-state" => {
                                "read" => true,
                                "write" => true
                            }
                        }
                    },
                    "exceptions" => {}
                }
            }
        },
        {
            "address" => [
                ("host" => "master"),
                ("server" => "server-one")
            ],
            "outcome" => "success",
            "result" => {
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {}
                    },
                    "exceptions" => {}
                },
                "description" => undefined
            }
        }
    ]
}

{noformat}

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 11:44:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 11:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.8238.1443023040157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFCORE-994:
-------------------------------
    Comment: was deleted

(was: On a related note: Can you verify why the following query only returns a single element in the response?

{noformat}
/host=*/server-config=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
{noformat}

Looking at the '/host=*:read-resource-description()' case, I would assume that it also returns a list of host responses)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 11:45:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 11:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.8244.1443023100241@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111781#comment-13111781 ] 

Heiko Braun edited comment on WFCORE-994 at 9/23/15 11:44 AM:
--------------------------------------------------------------

On a domain with two host controllers:

{noformat}
[domain at localhost:9990 /] :read-children-names(child-type=host)
{
    "outcome" => "success",
    "result" => [
        "macbook-pro.fritz.box",
        "master"
    ]
}

{noformat}

Can someone explain the difference between a) and b)?

a) 
{noformat}
[domain at localhost:9990 /] /host=*/server-config=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("host" => "master"),
            ("server-config" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            " capabilities" => [{
                "name" => "org.wildfly.domain.server-config",
                "dynamic" => true
            }],
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {
                "interface" => {"model-description" => undefined},
                "jvm" => {"model-description" => undefined},
                "path" => {"model-description" => undefined},
                "system-property" => {"model-description" => undefined}
            },
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "auto-start" => {
                            "read" => true,
                            "write" => true
                        },
                        "cpu-affinity" => {
                            "read" => true,
                            "write" => true
                        },
                        "group" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "priority" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-default-interface" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-group" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-port-offset" => {
                            "read" => true,
                            "write" => true
                        },
                        "status" => {
                            "read" => true,
                            "write" => true
                        },
                        "update-auto-start-with-server-status" => {
                            "read" => true,
                            "write" => true
                        }
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

{noformat}

b) 
{noformat}
[domain at localhost:9990 /] /host=*/server=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [
                ("host" => "master"),
                ("server" => "*")
            ],
            "outcome" => "success",
            "result" => {
                "description" => undefined,
                "attributes" => undefined,
                "operations" => undefined,
                "notifications" => undefined,
                "children" => {},
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "launch-type" => {
                                "read" => true,
                                "write" => true
                            },
                            "server-state" => {
                                "read" => true,
                                "write" => true
                            }
                        }
                    },
                    "exceptions" => {}
                }
            }
        },
        {
            "address" => [
                ("host" => "master"),
                ("server" => "server-one")
            ],
            "outcome" => "success",
            "result" => {
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {}
                    },
                    "exceptions" => {}
                },
                "description" => undefined
            }
        }
    ]
}

{noformat}


was (Author: heiko.braun):
Can someone explain the difference between a) and b)?

a) 
{noformat}
[domain at localhost:9990 /] /host=*/server-config=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("host" => "master"),
            ("server-config" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            " capabilities" => [{
                "name" => "org.wildfly.domain.server-config",
                "dynamic" => true
            }],
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {
                "interface" => {"model-description" => undefined},
                "jvm" => {"model-description" => undefined},
                "path" => {"model-description" => undefined},
                "system-property" => {"model-description" => undefined}
            },
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "auto-start" => {
                            "read" => true,
                            "write" => true
                        },
                        "cpu-affinity" => {
                            "read" => true,
                            "write" => true
                        },
                        "group" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "priority" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-default-interface" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-group" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-port-offset" => {
                            "read" => true,
                            "write" => true
                        },
                        "status" => {
                            "read" => true,
                            "write" => true
                        },
                        "update-auto-start-with-server-status" => {
                            "read" => true,
                            "write" => true
                        }
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

{noformat}

b) 
{noformat}
[domain at localhost:9990 /] /host=*/server=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [
                ("host" => "master"),
                ("server" => "*")
            ],
            "outcome" => "success",
            "result" => {
                "description" => undefined,
                "attributes" => undefined,
                "operations" => undefined,
                "notifications" => undefined,
                "children" => {},
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "launch-type" => {
                                "read" => true,
                                "write" => true
                            },
                            "server-state" => {
                                "read" => true,
                                "write" => true
                            }
                        }
                    },
                    "exceptions" => {}
                }
            }
        },
        {
            "address" => [
                ("host" => "master"),
                ("server" => "server-one")
            ],
            "outcome" => "success",
            "result" => {
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {}
                    },
                    "exceptions" => {}
                },
                "description" => undefined
            }
        }
    ]
}

{noformat}

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 11:46:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 11:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.8249.1443023160189@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111781#comment-13111781 ] 

Heiko Braun edited comment on WFCORE-994 at 9/23/15 11:45 AM:
--------------------------------------------------------------

On a domain with two host controllers:

{noformat}
[domain at localhost:9990 /] :read-children-names(child-type=host)
{
    "outcome" => "success",
    "result" => [
        "macbook-pro.fritz.box",
        "master"
    ]
}

{noformat}

Can someone explain the difference between a) and b)? And why is the second host not showing up?

a) 
{noformat}
[domain at localhost:9990 /] /host=*/server-config=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("host" => "master"),
            ("server-config" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            " capabilities" => [{
                "name" => "org.wildfly.domain.server-config",
                "dynamic" => true
            }],
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {
                "interface" => {"model-description" => undefined},
                "jvm" => {"model-description" => undefined},
                "path" => {"model-description" => undefined},
                "system-property" => {"model-description" => undefined}
            },
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "auto-start" => {
                            "read" => true,
                            "write" => true
                        },
                        "cpu-affinity" => {
                            "read" => true,
                            "write" => true
                        },
                        "group" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "priority" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-default-interface" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-group" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-port-offset" => {
                            "read" => true,
                            "write" => true
                        },
                        "status" => {
                            "read" => true,
                            "write" => true
                        },
                        "update-auto-start-with-server-status" => {
                            "read" => true,
                            "write" => true
                        }
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

{noformat}

b) 
{noformat}
[domain at localhost:9990 /] /host=*/server=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [
                ("host" => "master"),
                ("server" => "*")
            ],
            "outcome" => "success",
            "result" => {
                "description" => undefined,
                "attributes" => undefined,
                "operations" => undefined,
                "notifications" => undefined,
                "children" => {},
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "launch-type" => {
                                "read" => true,
                                "write" => true
                            },
                            "server-state" => {
                                "read" => true,
                                "write" => true
                            }
                        }
                    },
                    "exceptions" => {}
                }
            }
        },
        {
            "address" => [
                ("host" => "master"),
                ("server" => "server-one")
            ],
            "outcome" => "success",
            "result" => {
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {}
                    },
                    "exceptions" => {}
                },
                "description" => undefined
            }
        }
    ]
}

{noformat}


was (Author: heiko.braun):
On a domain with two host controllers:

{noformat}
[domain at localhost:9990 /] :read-children-names(child-type=host)
{
    "outcome" => "success",
    "result" => [
        "macbook-pro.fritz.box",
        "master"
    ]
}

{noformat}

Can someone explain the difference between a) and b)?

a) 
{noformat}
[domain at localhost:9990 /] /host=*/server-config=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("host" => "master"),
            ("server-config" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            " capabilities" => [{
                "name" => "org.wildfly.domain.server-config",
                "dynamic" => true
            }],
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {
                "interface" => {"model-description" => undefined},
                "jvm" => {"model-description" => undefined},
                "path" => {"model-description" => undefined},
                "system-property" => {"model-description" => undefined}
            },
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "auto-start" => {
                            "read" => true,
                            "write" => true
                        },
                        "cpu-affinity" => {
                            "read" => true,
                            "write" => true
                        },
                        "group" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "priority" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-default-interface" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-group" => {
                            "read" => true,
                            "write" => true
                        },
                        "socket-binding-port-offset" => {
                            "read" => true,
                            "write" => true
                        },
                        "status" => {
                            "read" => true,
                            "write" => true
                        },
                        "update-auto-start-with-server-status" => {
                            "read" => true,
                            "write" => true
                        }
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

{noformat}

b) 
{noformat}
[domain at localhost:9990 /] /host=*/server=*:read-resource-description(access-control=trim-descriptions)
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [
                ("host" => "master"),
                ("server" => "*")
            ],
            "outcome" => "success",
            "result" => {
                "description" => undefined,
                "attributes" => undefined,
                "operations" => undefined,
                "notifications" => undefined,
                "children" => {},
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "launch-type" => {
                                "read" => true,
                                "write" => true
                            },
                            "server-state" => {
                                "read" => true,
                                "write" => true
                            }
                        }
                    },
                    "exceptions" => {}
                }
            }
        },
        {
            "address" => [
                ("host" => "master"),
                ("server" => "server-one")
            ],
            "outcome" => "success",
            "result" => {
                "access-control" => {
                    "default" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {}
                    },
                    "exceptions" => {}
                },
                "description" => undefined
            }
        }
    ]
}

{noformat}

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 12:21:00 2015
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 23 Sep 2015 12:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.8434.1443025260206@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111804#comment-13111804 ] 

Heiko Braun commented on WFCORE-994:
------------------------------------

[~kabirkhan] kabir, please let me know whem you have something to look at. This issue is quiet complex for us and I think it's more simple to verify the changes then providing a complete specification of what we actually expect. 


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 12:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 12:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.8514.1443027120269@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111810#comment-13111810 ] 

Brian Stansberry commented on WFCORE-998:
-----------------------------------------

Ah, I didn't notice yesterday that the target address of the main request was [], not host=macbook/server=server-four. There is probably a bug in how the HC deals with a composite op for [] with steps that target specific remote processes such that it assumes it can proxy the request. What it does is build up this:

{code}
{
    "operation" => "composite",
    "address" => [
            ("host" => "macbook-pro.fritz.box"),
            ("server" => "server-four")
        ],
    "steps" => [{
        "address" => []],
        "operation" => "read-resource-description",
        "operations" => true,
        "access-control" => "combined-descriptions",
        "include-aliases" => true
    }]
}
{code}

and attempts to execute that step, assuming it will be proxied to the remote process. But for a stopped server, there is no ability to proxy the request to a remote server, and the local resource that exists on the HC for that stopped server tries to handle it and can't.

The fix for this would be to have the HC realize the server is not running and not use the handling that it normally uses for connected servers. (I'm thinking the fix is likely in HostControllerExecutionSupport).

If this is fixed, you're not going to get the same r-r-d for /host=macbook/server=server-four when it's not running as you do when it is running. A non-running server resource just exposes on or two status attributes and ops to start the server.

A workaround for this is to not wrap the request in a composite.

> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 12:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 12:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.8517.1443027120372@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-998:
------------------------------------
    Fix Version/s: 2.0.0.CR6


> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 12:56:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 12:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.8531.1443027360270@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111811#comment-13111811 ] 

Brian Stansberry commented on WFCORE-998:
-----------------------------------------

A simpler fix may be to register the composite op on the resource registration for a stopped server. This needs some thought.

> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 13:03:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Wed, 23 Sep 2015 13:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.8554.1443027780105@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111814#comment-13111814 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

TCPPING is what is commonly used.  So, I assume there is not more timeout setting for TCPPING?

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 13:13:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Sep 2015 13:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.8571.1443028380169@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111816#comment-13111816 ] 

Paul Ferraro commented on WFLY-5358:
------------------------------------

[~czacharym] pbcast.GMS is a different protocol which should also exist in your stack.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 13:24:00 2015
From: issues at jboss.org (Shobhan Ganta (JIRA))
Date: Wed, 23 Sep 2015 13:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9572) Jboss does hot deployment on
 its own while it is running without any file changes
In-Reply-To: <JIRA.12585828.1443028984000@Atlassian.JIRA>
References: <JIRA.12585828.1443028984000@Atlassian.JIRA>
	<JIRA.12585828.1443028984501@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585828.1443028984000.8588.1443029040182@Atlassian.JIRA>

Shobhan Ganta created JBAS-9572:
-----------------------------------

             Summary: Jboss does hot deployment on its own while it is running without any file changes
                 Key: JBAS-9572
                 URL: https://issues.jboss.org/browse/JBAS-9572
             Project: Application Server 3  4  5 and 6
          Issue Type: Bug
          Components: EE
    Affects Versions: 6.1.0
            Reporter: Shobhan Ganta
             Fix For: 6.1.0
         Attachments: jboss_server_issue.txt

We have deployed a J2EE application on Jboss 6.1 and we are experiencing JBoss hot deployment being executed with out any file changes in production. Jboss trying to perform HD scanner hot deploy and end up with the following deployment errors. please let us know your input/thoughts.

2015-09-22 22:08:18,452 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) (TomcatDeployment.java:533) undeploy, ctxPath=/
2015-09-22 22:08:18,737 INFO  [org.jboss.resource.connectionmanager.ConnectionFactoryBindingService] (HDScanner) (ConnectionFactoryBindingService.java:182) Unbound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' from JNDI name 'java:JmsXA'
2015-09-22 22:08:18,745 INFO  [org.hornetq.ra.HornetQResourceAdapter] (HDScanner) (Log4jLogDelegate.java:81) HornetQ resource adapter stopped
2015-09-22 22:08:18,755 WARN  [org.jboss.deployers.structure.spi.helpers.ComponentDeploymentContext] (HDScanner) (ComponentDeploymentContext.java:198) Removing name on null names: jboss.naming:application=jms-ra
2015-09-22 22:08:18,989 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) (TomcatDeployment.java:533) undeploy, ctxPath=/invoker
2015-09-22 22:08:19,017 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) (TomcatDeployment.java:533) undeploy, ctxPath=/aris
2015-09-22 22:08:19,483 INFO  [org.apache.coyote.http11.Http11Protocol] (HDScanner) (Http11Protocol.java:249) Pausing Coyote HTTP/1.1 on http-0.0.0.0-3020
2015-09-22 22:08:19,491 INFO  [org.apache.coyote.http11.Http11Protocol] (HDScanner) (Http11Protocol.java:265) Stopping Coyote HTTP/1.1 on http-0.0.0.0-3020
2015-09-22 22:08:19,519 INFO  [org.apache.coyote.ajp.AjpProtocol] (HDScanner) (AjpProtocol.java:233) Pausing Coyote AJP/1.3 on ajp-0.0.0.0-28001
2015-09-22 22:08:19,529 INFO  [org.apache.coyote.ajp.AjpProtocol] (HDScanner) (AjpProtocol.java:249) Stopping Coyote AJP/1.3 on ajp-0.0.0.0-28001
2015-09-22 22:08:21,964 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) (AbstractController.java:1103) Error installing to Real: name=vfs:///appl/cpc/jboss-6.1/server/default/deploy/http-invoker.sar state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Failed to create web module
	at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:485) [:6.1.0.Final]
	at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:122) [:6.1.0.Final]
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:63) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1603) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.2.GA]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
	at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
	at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0.05]
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0.05]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0.05]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0.05]
Caused by: java.lang.ClassCastException: org.jboss.web.tomcat.service.deployers.TomcatDeployment cannot be cast to org.jboss.web.tomcat.service.deployers.TomcatDeployment
	at org.jboss.web.tomcat.service.deployers.TomcatDeployer.getDeployment(TomcatDeployer.java:410) [:6.1.0.Final]
	at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:477) [:6.1.0.Final]
	... 42 more

2015-09-22 22:08:23,319 INFO  [org.apache.catalina.core.AprLifecycleListener] (HDScanner) (AprLifecycleListener.java:141) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /appl/cpc/jboss-6.1/bin/native/lib
2015-09-22 22:08:24,042 INFO  [org.apache.coyote.http11.Http11Protocol] (HDScanner) (Http11Protocol.java:219) Starting Coyote HTTP/1.1 on http-0.0.0.0-3020
2015-09-22 22:08:24,064 INFO  [org.apache.coyote.ajp.AjpProtocol] (HDScanner) (AjpProtocol.java:203) Starting Coyote AJP/1.3 on ajp-0.0.0.0-28001
2015-09-22 22:08:24,076 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) (AbstractController.java:1103) Error installing to Configured: name=JmxConsoleActivator state=Instantiated: java.lang.RuntimeException: Error configuring property: onDemandContextIntegrator for JmxConsoleActivator
	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44) [:6.1.0.Final]
	at sun.reflect.GeneratedMethodAccessor291.invoke(Unknown Source) [:1.6.0.05]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0.05]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0.05]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.2.GA]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:63) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.2.GA]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
	at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
	at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0.05]
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0.05]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0.05]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0.05]
Caused by: java.lang.IllegalArgumentException: Wrong arguments. setOnDemandContextIntegrator for target org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager at 1d3fd22 expected=[org.jboss.web.tomcat.service.ondemand.OnDemandContextIntegrator] actual=[org.jboss.web.tomcat.service.ondemand.DefaultOnDemandContextIntegrator]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:404) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:74) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.BeanInfoUtil.set(BeanInfoUtil.java:177) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.setProperty(AbstractBeanInfo.java:289) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:114) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.SP2]
	... 78 more

2015-09-22 22:08:24,134 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) (AbstractController.java:1103) Error installing to Configured: name=JBossWSConsoleActivator state=Instantiated: java.lang.RuntimeException: Error configuring property: onDemandContextIntegrator for JBossWSConsoleActivator
	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44) [:6.1.0.Final]
	at sun.reflect.GeneratedMethodAccessor291.invoke(Unknown Source) [:1.6.0.05]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0.05]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0.05]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.2.GA]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:63) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.2.GA]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
	at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
	at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0.05]
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0.05]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0.05]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0.05]
Caused by: java.lang.IllegalArgumentException: Wrong arguments. setOnDemandContextIntegrator for target org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager at 1b60831 expected=[org.jboss.web.tomcat.service.ondemand.OnDemandContextIntegrator] actual=[org.jboss.web.tomcat.service.ondemand.DefaultOnDemandContextIntegrator]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:404) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:74) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.BeanInfoUtil.set(BeanInfoUtil.java:177) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.setProperty(AbstractBeanInfo.java:289) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:114) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.SP2]
	... 78 more

2015-09-22 22:08:24,182 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) (AbstractController.java:1103) Error installing to Configured: name=AdminConsoleActivator state=Instantiated: java.lang.RuntimeException: Error configuring property: onDemandContextIntegrator for AdminConsoleActivator
	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44) [:6.1.0.Final]
	at sun.reflect.GeneratedMethodAccessor291.invoke(Unknown Source) [:1.6.0.05]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0.05]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0.05]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.2.GA]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:63) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.2.GA]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
	at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
	at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0.05]
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0.05]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0.05]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0.05]
Caused by: java.lang.IllegalArgumentException: Wrong arguments. setOnDemandContextIntegrator for target org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager at bb126a expected=[org.jboss.web.tomcat.service.ondemand.OnDemandContextIntegrator] actual=[org.jboss.web.tomcat.service.ondemand.DefaultOnDemandContextIntegrator]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:404) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:74) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.BeanInfoUtil.set(BeanInfoUtil.java:177) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.setProperty(AbstractBeanInfo.java:289) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:114) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.SP2]
	... 78 more

2015-09-22 22:08:24,213 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) (AbstractController.java:1103) Error installing to Start: name=jboss.web.deployment:war=/aris state=Create mode=Manual requiredState=Installed: java.lang.IllegalStateException: WebModules cannot be restarted, and must be redeployed
	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:115) [:6.1.0.Final]
	at org.jboss.web.deployers.WebModule.start(WebModule.java:95) [:6.1.0.Final]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0.05]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0.05]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0.05]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0.05]
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) [:2.2.0.SP2]
	at $Proxy41.start(Unknown Source)	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:53) [:2.2.0.SP2]
	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:41) [:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301) [:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)]
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44) [:6.1.0.Final]
	at sun.reflect.GeneratedMethodAccessor291.invoke(Unknown Source) [:1.6.0.05]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0.05]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0.05]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.2.GA]
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:63) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.2.GA]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
	at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
	at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0.05]
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0.05]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0.05]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0.05]

2015-09-22 22:08:24,984 INFO  [org.jboss.modcluster.ModClusterService] (HDScanner) (ModClusterService.java:133) Initializing mod_cluster 1.1.0.Final
2015-09-22 22:08:25,496 INFO  [org.jboss.resource.deployers.RARDeployment] (HDScanner) (RARDeployment.java:146) Required license terms exist, view vfs:/appl/cpc/jboss-6.1/server/default/deploy/jms-ra.rar/META-INF/ra.xml
2015-09-22 22:08:25,585 INFO  [org.hornetq.ra.HornetQResourceAdapter] (HDScanner) (Log4jLogDelegate.java:81) HornetQ resource adaptor started
2015-09-22 22:08:25,742 INFO  [org.jboss.resource.connectionmanager.ConnectionFactoryBindingService] (HDScanner) (ConnectionFactoryBindingService.java:160) Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
2015-09-22 22:08:25,918 INFO  [org.jboss.xnio.nio] (HDScanner) (NioXnio.java:94) XNIO NIO Implementation Version 2.1.0.CR2
2015-09-22 22:08:25,937 WARN  [org.jboss.xnio.nio] (HDScanner) (NioXnio.java:236) The currently defined selector provider class (sun.nio.ch.PollSelectorProvider) is not supported for use with XNIO
2015-09-22 22:08:26,141 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) (AbstractController.java:1103) Error installing to Real: name=vfs:///appl/cpc/jboss-6.1/server/default/deploy/ROOT.war state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Failed to create web module
	at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:485) [:6.1.0.Final]
	at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:122) [:6.1.0.Final]
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:63) [:2.2.2.GA]
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.2.GA]
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
	at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
	at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0.05]
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0.05]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0.05]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0.05]
Caused by: java.lang.ClassCastException: org.jboss.web.tomcat.service.deployers.TomcatDeployment cannot be cast to org.jboss.web.tomcat.service.deployers.TomcatDeployment
	at org.jboss.web.tomcat.service.deployers.TomcatDeployer.getDeployment(TomcatDeployer.java:410) [:6.1.0.Final]
	at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:477) [:6.1.0.Final]
	... 41 more

2015-09-22 22:08:26,215 WARN  [org.jboss.profileservice.deployment.hotdeploy.HDScanner] (HDScanner) (HDScanner.java:150) Scan failed: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** DEPLOYMENTS IN ERROR: Name -> Error

vfs:///appl/cpc/jboss-6.1/server/default/deploy/ROOT.war -> org.jboss.deployers.spi.DeploymentException: Failed to create web module

vfs:///appl/cpc/jboss-6.1/server/default/deploy/http-invoker.sar -> org.jboss.deployers.spi.DeploymentException: Failed to create web module


DEPLOYMENTS IN ERROR:
  Deployment "vfs:///appl/cpc/jboss-6.1/server/default/deploy/http-invoker.sar" is in error due to the following reason(s): java.lang.ClassCastException: org.jboss.web.tomcat.service.deployers.TomcatDeployment cannot be cast to org.jboss.web.tomcat.service.deployers.TomcatDeployment
  Deployment "vfs:///appl/cpc/jboss-6.1/server/default/deploy/ROOT.war" is in error due to the following reason(s): java.lang.ClassCastException: org.jboss.web.tomcat.service.deployers.TomcatDeployment cannot be cast to org.jboss.web.tomcat.service.deployers.TomcatDeployment

	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.2.GA]
	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.2.GA]
	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:968) [:2.2.2.GA]
	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.checkComplete(MainDeployerPlugin.java:82) [:6.1.0.Final]
	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.checkComplete(ProfileControllerContext.java:138) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:246) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
	at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
	at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
	at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
	at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
	at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0.05]
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0.05]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0.05]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0.05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0.05]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0.05]

 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 14:42:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Wed, 23 Sep 2015 14:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.8813.1443033720892@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111842#comment-13111842 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

Paul, we already currently have an environment Running on WFLY 8.2.1 using the HA profile with TCPPING for cluster.  This worked fine for us and wanted to replication this setup in WFLY 10.  Are you telling me there is no timeout of any time, however named for TCPPING now?  Why was this removed?  If you look at any of the Cluster setup examples out there, a majority use TCPPING.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 14:49:00 2015
From: issues at jboss.org (The Alchemist (JIRA))
Date: Wed, 23 Sep 2015 14:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3812) Package-private access
 doesn't work since Weld 2.2.4
In-Reply-To: <JIRA.12551088.1409830804000@Atlassian.JIRA>
References: <JIRA.12551088.1409830804000@Atlassian.JIRA>
	<JIRA.12551088.1409830804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551088.1409830804000.8934.1443034140164@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111847#comment-13111847 ] 

The Alchemist commented on WFLY-3812:
-------------------------------------

Odd, I'm using Wildfly 9.0.1.Final, but I still this warning:

{noformat}
18:46:12,057 WARN  [org.jboss.as.weld] (default task-91) WFLYWELD0052: Using deployment classloader to load proxy classes for module org.picketlink.core.api:main. Package-private access will not work. To fix this the module should declare dependencies on [org.jboss.weld.core, org.jboss.weld.spi]

{noformat}

> Package-private access doesn't work since Weld 2.2.4
> ----------------------------------------------------
>
>                 Key: WFLY-3812
>                 URL: https://issues.jboss.org/browse/WFLY-3812
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>             Fix For: 8.2.0.Final, 9.0.0.Alpha1
>
>
> The WildFly snapshot for 9.0.0.Alpha1 submits the serious warning below, when PicketLink is used. This warning is a result of upgrading to Weld 2.2.4. Please make the fix (at the bottom) before releasing WFLY 9. Thank you.
> {code}
> WARN  [org.jboss.as.weld] WFLYWELD0052:
> Using deployment classloader to load proxy classes for module org.picketlink.core:main.
> Package-private access will not work. To fix this the module should declare dependencies on [org.jboss.weld.core, org.jboss.weld.spi]
> {code}
> The fix is:
> In file feature-pack/src/main/resources/modules/system/layers/base/org/picketlink/core/main/module.xml add these two lines within the <dependencies> block:
> {code}
> <module name="org.jboss.weld.core"/>
> <module name="org.jboss.weld.spi"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 14:50:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Wed, 23 Sep 2015 14:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5397) WeldDeployment is returning
 the wrong BDA for the specified beanClass
In-Reply-To: <JIRA.12585835.1443034183000@Atlassian.JIRA>
References: <JIRA.12585835.1443034183000@Atlassian.JIRA>
	<JIRA.12585835.1443034183822@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585835.1443034183000.8938.1443034200312@Atlassian.JIRA>

Jason Greene created WFLY-5397:
----------------------------------

             Summary: WeldDeployment is returning the wrong BDA for the specified beanClass
                 Key: WFLY-5397
                 URL: https://issues.jboss.org/browse/WFLY-5397
             Project: WildFly
          Issue Type: Bug
            Reporter: Jason Greene
            Assignee: Jason Greene
             Fix For: 10.0.0.CR2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 14:54:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Sep 2015 14:54:00 -0400 (EDT)
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.8947.1443034440118@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111850#comment-13111850 ] 

Paul Ferraro commented on WFLY-4805:
------------------------------------

[~mbabacek] Can you try to reproduce this with the latest release?

> 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: Paul Ferraro
>         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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 15:57:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 15:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1004) Do not support expressions
 on the management-interface=http-interface 'http-upgrade' attribute
In-Reply-To: <JIRA.12585867.1443038170000@Atlassian.JIRA>
References: <JIRA.12585867.1443038170000@Atlassian.JIRA>
	<JIRA.12585867.1443038170150@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585867.1443038170000.9359.1443038220054@Atlassian.JIRA>

Brian Stansberry created WFCORE-1004:
----------------------------------------

             Summary: Do not support expressions on the management-interface=http-interface 'http-upgrade' attribute
                 Key: WFCORE-1004
                 URL: https://issues.jboss.org/browse/WFCORE-1004
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR5


Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we won't to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.

Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems.

Changing this, however, will be a breaking API change vs WF 8/9.

I expect using an expression for this attribute will have been quite unusual.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 15:58:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 15:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1004) Do not support expressions
 on the management-interface=http-interface 'http-upgrade' attribute
In-Reply-To: <JIRA.12585867.1443038170000@Atlassian.JIRA>
References: <JIRA.12585867.1443038170000@Atlassian.JIRA>
	<JIRA.12585867.1443038170000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585867.1443038170000.9362.1443038280094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1004:
-------------------------------------
    Description: 
Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we want to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.

Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems.

Changing this, however, will be a breaking API change vs WF 8/9.

I expect using an expression for this attribute will have been quite unusual.

  was:
Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we won't to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.

Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems.

Changing this, however, will be a breaking API change vs WF 8/9.

I expect using an expression for this attribute will have been quite unusual.



> Do not support expressions on the management-interface=http-interface 'http-upgrade' attribute
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1004
>                 URL: https://issues.jboss.org/browse/WFCORE-1004
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR5
>
>
> Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we want to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.
> Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems.
> Changing this, however, will be a breaking API change vs WF 8/9.
> I expect using an expression for this attribute will have been quite unusual.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 15:59:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 15:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1004) Do not support expressions
 on the management-interface=http-interface 'http-upgrade' attribute
In-Reply-To: <JIRA.12585867.1443038170000@Atlassian.JIRA>
References: <JIRA.12585867.1443038170000@Atlassian.JIRA>
	<JIRA.12585867.1443038170000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585867.1443038170000.9364.1443038340058@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1004:
-------------------------------------
    Description: 
Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we want to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.

Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems when we move to a resource.

Changing this, however, will be a breaking API change vs WF 8/9.

I expect using an expression for this attribute will have been quite unusual.

  was:
Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we want to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.

Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems.

Changing this, however, will be a breaking API change vs WF 8/9.

I expect using an expression for this attribute will have been quite unusual.



> Do not support expressions on the management-interface=http-interface 'http-upgrade' attribute
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1004
>                 URL: https://issues.jboss.org/browse/WFCORE-1004
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR5
>
>
> Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we want to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.
> Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems when we move to a resource.
> Changing this, however, will be a breaking API change vs WF 8/9.
> I expect using an expression for this attribute will have been quite unusual.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 16:15:02 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 16:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1004) Do not support expressions
 on the management-interface=http-interface 'http-upgrade' attribute
In-Reply-To: <JIRA.12585867.1443038170000@Atlassian.JIRA>
References: <JIRA.12585867.1443038170000@Atlassian.JIRA>
	<JIRA.12585867.1443038170000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585867.1443038170000.9379.1443039302310@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111909#comment-13111909 ] 

Brian Stansberry commented on WFCORE-1004:
------------------------------------------

I'd forgotten that the expression is only supported on the host.xml http interface, not on the server one. So even more of a corner case.

> Do not support expressions on the management-interface=http-interface 'http-upgrade' attribute
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1004
>                 URL: https://issues.jboss.org/browse/WFCORE-1004
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR5
>
>
> Our intent is to shift configuration of JBoss Remoting based management via HTTP Upgrade to use a child resource. This is needed as we want to implement this as a capability and we only want resource to provide capabilities, not attributes. Also, I suspect it will turn out to be a better API as a resource anyway, as a resource can support more than just the "off/on" behavior of the current attribute.
> Allowing expressions for this attribute will make this transition much harder. I would prefer to never allow an expression for this attribute in EAP, as that will avoid any EAP compatibility problems when we move to a resource.
> Changing this, however, will be a breaking API change vs WF 8/9.
> I expect using an expression for this attribute will have been quite unusual.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 18:36:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 23 Sep 2015 18:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.9548.1443047760179@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFLY-3990:
-----------------------------------

    Assignee: James Perkins  (was: Tomaz Cerar)


> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE, EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>            Assignee: James Perkins
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 18:44:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 23 Sep 2015 18:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.9552.1443048240166@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111940#comment-13111940 ] 

James Perkins commented on WFLY-3990:
-------------------------------------

I don't think a default value should be used. It's easy enough to add a value if needed. If you want an unbounded queue keep the {{core-threads}} at a value greater than 0 and set the {{queue-length}} to {{MAX_INT}} (2147483647).

> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE, EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>            Assignee: James Perkins
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 18:52:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Sep 2015 18:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5372) Infinispan's jdbc store
 creates incorrect service name for datasource dependency
In-Reply-To: <JIRA.12585434.1442698974000@Atlassian.JIRA>
References: <JIRA.12585434.1442698974000@Atlassian.JIRA>
	<JIRA.12585434.1442698974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585434.1442698974000.9561.1443048720115@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned WFLY-5372:
----------------------------------

    Assignee: Paul Ferraro  (was: Radoslav Husar)


> Infinispan's jdbc store creates incorrect service name for datasource dependency
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5372
>                 URL: https://issues.jboss.org/browse/WFLY-5372
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR2
>
>
> fails with
> 23:36:38,116 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "clusterbench-ee7.ear")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
>     "Services that were unable to start:" => [
>         "jboss.clustering.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\"",
>         "jboss.clustering.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\"",
>         "jboss.clustering.web.locator.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\"",
>         "jboss.clustering.web.locator.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\"",
>         "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-web-default.war\".deploymentCompleteService",
>         "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-web-passivating.war\".deploymentCompleteService",
>         "jboss.deployment.unit.\"clusterbench-ee7.ear\".deploymentCompleteService",
>         "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\"",
>         "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-default.war\".config",
>         "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\"",
>         "jboss.infinispan.web.\"clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war\".config",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench.UndertowDeploymentInfoService",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench.codec",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench.session",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating.UndertowDeploymentInfoService",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating.codec",
>         "jboss.undertow.deployment.default-server.default-host./clusterbench-passivating.session"
>     ],
>     "Services that may be the cause:" => ["jboss.data-source.java:jboss/datasources/ExampleDS"]
> }}
> 23:36:38,119 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "infinispan"),
>     ("cache-container" => "web")
> ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
>     "Services that were unable to start:" => [
>         "jboss.clustering.registry.web.default",
>         "jboss.infinispan.web.default.config"
>     ],
>     "Services that may be the cause:" => ["jboss.data-source.java:jboss/datasources/ExampleDS"]
> }}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 20:55:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Sep 2015 20:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1005)
 HostControllerConnectionService does not let in flight requests clear
 before stopping
In-Reply-To: <JIRA.12585886.1443056081000@Atlassian.JIRA>
References: <JIRA.12585886.1443056081000@Atlassian.JIRA>
	<JIRA.12585886.1443056081370@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585886.1443056081000.9607.1443056100058@Atlassian.JIRA>

Brian Stansberry created WFCORE-1005:
----------------------------------------

             Summary: HostControllerConnectionService does not let in flight requests clear before stopping
                 Key: WFCORE-1005
                 URL: https://issues.jboss.org/browse/WFCORE-1005
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.CR4
            Reporter: Brian Stansberry


HostControllerConnectionService sets up a remoting channel that receives management requests. But unlike the services that receive end user mgmt requests, it makes no effort to ensure in flight requests have cleared before shutting down.

I haven't looked but I wouldn't be surprised if there's a similar problem with the channel a slave HC opens for communication with the master.

I don't think this is a critical problem; when the service stop ends up closing the channel the remote end will be notified and the in flight request should report a failure. That failure may be unnecessary though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 21:49:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 23 Sep 2015 21:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.9657.1443059340163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111940#comment-13111940 ] 

James Perkins edited comment on WFLY-3990 at 9/23/15 9:48 PM:
--------------------------------------------------------------

I don't think a default value should be used. It's easy enough to add a value if needed. If you want an unbounded queue keep the {{core-threads}} at a value greater than 0 and set the {{queue-length}} to {{Integer.MAX_VALUE}} (2147483647).


was (Author: jamezp):
I don't think a default value should be used. It's easy enough to add a value if needed. If you want an unbounded queue keep the {{core-threads}} at a value greater than 0 and set the {{queue-length}} to {{MAX_INT}} (2147483647).

> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE, EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>            Assignee: James Perkins
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 23 23:16:01 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 23 Sep 2015 23:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5398) JASPIC sam not invoked again
 if authenticate() is called
In-Reply-To: <JIRA.12585888.1443064542000@Atlassian.JIRA>
References: <JIRA.12585888.1443064542000@Atlassian.JIRA>
	<JIRA.12585888.1443064542042@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585888.1443064542000.9674.1443064561676@Atlassian.JIRA>

Stuart Douglas created WFLY-5398:
------------------------------------

             Summary: JASPIC sam not invoked again if authenticate() is called
                 Key: WFLY-5398
                 URL: https://issues.jboss.org/browse/WFLY-5398
             Project: WildFly
          Issue Type: Bug
            Reporter: Stuart Douglas
            Assignee: Jason Greene






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 02:03:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 24 Sep 2015 02:03:00 -0400 (EDT)
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.9720.1443074580310@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111964#comment-13111964 ] 

Amos Feng commented on WFLY-5100:
---------------------------------

It looks like that it's missing some classes and I'm investigating.

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 02:20:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 24 Sep 2015 02:20:00 -0400 (EDT)
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.9748.1443075600774@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111966#comment-13111966 ] 

Amos Feng commented on WFLY-5100:
---------------------------------

org/apache/activemq/artemis/core/journal/SequentialFileFactory.class has been changed to
org/apache/activemq/artemis/core/io/SequentialFileFactory.class when activemq-artimes upgrades from 1.0.0 to 1.1.0-wildfly-6

So I think we need to change in narayana at first. I create JBTM-2523 for fixing this issue.

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 02:46:01 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Thu, 24 Sep 2015 02:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5399) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111984@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.9832.1443077161072@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5399:
--------------------------------------

             Summary: :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
                 Key: WFLY-5399
                 URL: https://issues.jboss.org/browse/WFLY-5399
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ond?ej Chaloupka
            Assignee: Brian Stansberry


When I use migration operation the console log is filled with warning messages of type

{{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}

This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
{code}
[standalone at localhost:9999 /] /subsystem=jacorb:migrate()
{
    "outcome" => "success",
    "result" => {"migration-warnings" => []}
}
[standalone at localhost:9999 /] /subsystem=messaging:migrate()
{
    "outcome" => "success",
    "result" => {"migration-warnings" => []}
}
[standalone at localhost:9999 /] /subsystem=we
web  webservices  weld  
[standalone at localhost:9999 /] /subsystem=web
web  webservices  
[standalone at localhost:9999 /] /subsystem=web:migrate()
{
    "outcome" => "success",
    "result" => {"migration-warnings" => []}
}
{code}

then I the log looks like
{code}
2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("jms-queue" => "DLQ")
]
2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("jms-queue" => "ExpiryQueue")
]
2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("pooled-connection-factory" => "hornetq-ra")
]
2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("connection-factory" => "RemoteConnectionFactory")
]
2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("connection-factory" => "InVmConnectionFactory")
]
2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("address-setting" => "#")
]
2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("security-setting" => "#"),
    ("role" => "guest")
]
2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("security-setting" => "#")
]
2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("in-vm-acceptor" => "in-vm")
]
2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("remote-acceptor" => "netty-throughput"),
    ("param" => "direct-deliver")
]
2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("remote-acceptor" => "netty-throughput"),
    ("param" => "batch-delay")
]
2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("remote-acceptor" => "netty-throughput")
]
2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("remote-acceptor" => "netty")
]
2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("in-vm-connector" => "in-vm")
]
2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("remote-connector" => "netty-throughput"),
    ("param" => "batch-delay")
]
2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("remote-connector" => "netty-throughput")
]
2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("remote-connector" => "netty")
]
2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default")
]
2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "web"),
    ("configuration" => "jsp-configuration")
]
2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "web"),
    ("configuration" => "static-resources")
]
2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "web"),
    ("configuration" => "container")
]
2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "web"),
    ("virtual-server" => "default-host")
]
2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
    ("subsystem" => "web"),
    ("connector" => "http")
]
2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
{code}

I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 02:46:01 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Thu, 24 Sep 2015 02:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5399) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.9835.1443077161209@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5399:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5399
>                 URL: https://issues.jboss.org/browse/WFLY-5399
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Brian Stansberry
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 02:59:01 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 24 Sep 2015 02:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5394) Netty acceptor is ignored in
 configuration and not opened
In-Reply-To: <JIRA.12585794.1443017471000@Atlassian.JIRA>
References: <JIRA.12585794.1443017471000@Atlassian.JIRA>
	<JIRA.12585794.1443017471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585794.1443017471000.9857.1443077941123@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111974#comment-13111974 ] 

Miroslav Novak commented on WFLY-5394:
--------------------------------------

Ok, I'll use remote-acceptor instead. I agree that using class names in configuration is not best way to configure acceptor and should be used just in cases when normal netty acceptor cannot be configured.

I've attached config where I did some tries and removed messaging socket binding. It was attached by accident. Socket binding must be configured.

> Netty acceptor is ignored in configuration and not opened 
> ----------------------------------------------------------
>
>                 Key: WFLY-5394
>                 URL: https://issues.jboss.org/browse/WFLY-5394
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> If netty acceptor is configured then port is not opened:
> {code}
> <acceptor name="netty" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory" socket-binding="messaging"/>
> {code}
> after server is started. Setting higher priority because it's core functionality.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 03:14:00 2015
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Thu, 24 Sep 2015 03:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-293) Add file based auth to http
 management interface
In-Reply-To: <JIRA.12487616.1363783129000@Atlassian.JIRA>
References: <JIRA.12487616.1363783129000@Atlassian.JIRA>
	<JIRA.12487616.1363783129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487616.1363783129000.9889.1443078840200@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111980#comment-13111980 ] 

Max Rydahl Andersen commented on ELY-293:
-----------------------------------------

[~dlofthouse] i'm not fully uptodate on the new namings. What does it change/imply that it will be an Elytron auth mechanism ? 

> Add file based auth to http management interface
> ------------------------------------------------
>
>                 Key: ELY-293
>                 URL: https://issues.jboss.org/browse/ELY-293
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Max Rydahl Andersen
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha1
>
>
> usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 03:15:01 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Sep 2015 03:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-858) NoSuchMethodError on JIT
 Compilation of non-primitive comparison
In-Reply-To: <JIRA.12579278.1437730819000@Atlassian.JIRA>
References: <JIRA.12579278.1437730819000@Atlassian.JIRA>
	<JIRA.12579278.1437730819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579278.1437730819000.9902.1443078901760@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111982#comment-13111982 ] 

RH Bugzilla Integration commented on DROOLS-858:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1252178|https://bugzilla.redhat.com/show_bug.cgi?id=1252178] from NEW to MODIFIED

> NoSuchMethodError on JIT Compilation of non-primitive comparison
> ----------------------------------------------------------------
>
>                 Key: DROOLS-858
>                 URL: https://issues.jboss.org/browse/DROOLS-858
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Beta2
>            Reporter: Sascha Dirbach
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.CR1
>
>         Attachments: ConditionEvaluator898a83b4ea6745eaa1b63420a059d717.class
>
>
> A LHS like this:
> {code}
> $map : Map()
> $simpleTestObject : NonStringConstructorClass (something=="simpleTestObject")
> Entry (
>   getKey() == $simpleTestObject
> ) from $map.entrySet()
> {code}
> fails at runtime with a NoSuchMethodError, when incompatible objects are compared (Map with object vs. custom Object) and the execution is jitted.
> The generated evaluation method looks like this:
> {code}
>   public boolean evaluate(InternalFactHandle paramInternalFactHandle, InternalWorkingMemory paramInternalWorkingMemory, LeftTuple paramLeftTuple)
>   {
>     LeftTuple localLeftTuple = paramLeftTuple;
>     NonStringConstructorClass localNonStringConstructorClass2 = (NonStringConstructorClass)this.declarations[0].getValue(paramInternalWorkingMemory, localLeftTuple.getHandle().getObject());
>     Object localObject = ((Map.Entry)paramInternalFactHandle.getObject()).getKey();
>     NonStringConstructorClass localNonStringConstructorClass1 = localNonStringConstructorClass2;
>     if (localObject != null)
>     {
>       if ((localObject instanceof NonStringConstructorClass)) {
>         localObject = (NonStringConstructorClass)localObject;
>       } else {
>         localObject = new NonStringConstructorClass(localObject.toString());
>       }
>     }
>     else
>     {
>       tmpTernaryOp = (localNonStringConstructorClass1 != null ? 0 : true;
>       break label123;
>     }
>     label123:
>     return localNonStringConstructorClass1 == null ? false : ((NonStringConstructorClass)localObject).equals(localNonStringConstructorClass1);
>   }
> }
> {code}
> It seem that, a fallback for primitive types was included, by calling the constructor of an object with the object's toString() output:
> {code}
> localObject = new NonStringConstructorClass(localObject.toString());
> {code}
> At runtime this fails, if no such constructor exists.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 03:41:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Sep 2015 03:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-913) Memory leak when deleting a
 tuple from an unlinked segment
In-Reply-To: <JIRA.12584856.1442245949000@Atlassian.JIRA>
References: <JIRA.12584856.1442245949000@Atlassian.JIRA>
	<JIRA.12584856.1442245949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584856.1442245949000.9928.1443080460210@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111988#comment-13111988 ] 

RH Bugzilla Integration commented on DROOLS-913:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1263496|https://bugzilla.redhat.com/show_bug.cgi?id=1263496] from NEW to MODIFIED

> Memory leak when deleting a tuple from an unlinked segment
> ----------------------------------------------------------
>
>                 Key: DROOLS-913
>                 URL: https://issues.jboss.org/browse/DROOLS-913
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>
> When deleting an object from a session all references to the object itself and the fact handle holding it should disappear. Unfortunately, as demonstrated by the test case below, in some case the deleted fact can remain as a deleted left tuple in the memory of an unlinked segment.
> {code}
>     @Test
>     public void testBetaMemoryLeakOnFactDelete() {
>         String drl =
>                 "rule R1 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "    $c : Integer(this == 2)\n" +
>                 "then \n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "    $a : Integer(this == 1)\n" +
>                 "    $b : String()\n" +
>                 "then \n" +
>                 "end\n";
>         KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
>                                              .build()
>                                              .newKieSession();
>         FactHandle fh1 = ksession.insert(1);
>         FactHandle fh2 = ksession.insert("test");
>         ksession.fireAllRules();
>         ksession.delete(fh1);
>         ksession.delete(fh2);
>         ksession.fireAllRules();
>         NodeMemories nodeMemories = ((InternalWorkingMemory) ksession).getNodeMemories();
>         for (int i = 0; i < nodeMemories.length(); i++) {
>             Memory memory = nodeMemories.peekNodeMemory( i );
>             if ( memory != null && memory.getSegmentMemory() != null ) {
>                 SegmentMemory segmentMemory = memory.getSegmentMemory();
>                 System.out.println( memory );
>                 LeftTuple deleteFirst = memory.getSegmentMemory().getStagedLeftTuples().getDeleteFirst();
>                 System.out.println( deleteFirst );
>                 assertNull( deleteFirst );
>             }
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 04:06:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Sep 2015 04:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.9982.1443081960101@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111997#comment-13111997 ] 

RH Bugzilla Integration commented on DROOLS-924:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1264541|https://bugzilla.redhat.com/show_bug.cgi?id=1264541] from ASSIGNED to MODIFIED

> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 04:47:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Sep 2015 04:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-855) Intermittent Disconnection
 from CLI After Reload in domain mode
In-Reply-To: <JIRA.12580049.1438354335000@Atlassian.JIRA>
References: <JIRA.12580049.1438354335000@Atlassian.JIRA>
	<JIRA.12580049.1438354335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580049.1438354335000.10426.1443084420270@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112015#comment-13112015 ] 

RH Bugzilla Integration commented on WFCORE-855:
------------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1249031|https://bugzilla.redhat.com/show_bug.cgi?id=1249031] from ON_QA to VERIFIED

> Intermittent Disconnection from CLI After Reload in domain mode
> ---------------------------------------------------------------
>
>                 Key: WFCORE-855
>                 URL: https://issues.jboss.org/browse/WFCORE-855
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha12
>            Reporter: Joe Wertz
>            Assignee: Joe Wertz
>             Fix For: 2.0.0.Alpha13
>
>   Original Estimate: 3 minutes
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>
> Description of problem:
>  CLI scripts for management of managed domain 
> Version-Release number of selected component (if applicable):
>  6.4.3.CP.CR1
> How reproducible:
>  Always
> Steps to Reproduce:
> Use CLI script:
> :read-attribute(name=process-type)
> reload --host=master
> :read-attribute(name=process-type)
> or commands option for script
> Actual results:
> 6.4.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
>     "outcome" => "success",
>     "result" => "Domain Controller"
> }
> Failed to establish connection in 6025ms
> Expected results:
> 6.3.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
>     "outcome" => "success",
>     "result" => "Domain Controller"
> }
> {
>     "outcome" => "success",
>     "result" => "Domain Controller"
> }
> Additional info:
>  - Follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1232933
>  - using --timeout doesn't workaround the problem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 04:57:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 24 Sep 2015 04:57:00 -0400 (EDT)
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.10473.1443085020137@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112022#comment-13112022 ] 

Amos Feng commented on WFLY-5100:
---------------------------------

Hi Ondra,

I just create JBTM-2525 to add a test for use-journal-store in our CI script. Can you share any similar test script if possible ?

Thanks,
Amos

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 05:26:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Thu, 24 Sep 2015 05:26:00 -0400 (EDT)
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.10560.1443086760198@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112031#comment-13112031 ] 

Ond?ej Chaloupka commented on WFLY-5100:
----------------------------------------

Hi Amos,

 we do not have directly some cli script that we would run to test. We have rather testsuites where we try to set it up.

What do you think, would not be better to add a testcase for the journal types and other basic transaction subsystem settings to WFLY testsuite, probably under {{testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/transaction/management}}? Similarly there are already tests like {{integration/basic/src/test/java/org/jboss/as/test/integration/ejb/management
}} or {{integration/basic/target/test-classes/org/jboss/as/test/integration/jpa/hibernate/management}}.

Ondra

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 05:26:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Thu, 24 Sep 2015 05:26:00 -0400 (EDT)
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.10564.1443086760570@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112031#comment-13112031 ] 

Ond?ej Chaloupka edited comment on WFLY-5100 at 9/24/15 5:25 AM:
-----------------------------------------------------------------

Hi Amos,

 we do not have directly some cli script that we would run to test. We have rather testsuites where we try to set it up.

What do you think, would not be better to add a testcase for the journal types and other basic transaction subsystem settings to WFLY testsuite, probably under {{testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/transaction/management}}? Similarly there are already tests like {{integration/basic/src/test/java/org/jboss/as/test/integration/ejb/management}}
or {{integration/basic/target/test-classes/org/jboss/as/test/integration/jpa/hibernate/management}}.

Ondra


was (Author: ochaloup):
Hi Amos,

 we do not have directly some cli script that we would run to test. We have rather testsuites where we try to set it up.

What do you think, would not be better to add a testcase for the journal types and other basic transaction subsystem settings to WFLY testsuite, probably under {{testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/transaction/management}}? Similarly there are already tests like {{integration/basic/src/test/java/org/jboss/as/test/integration/ejb/management
}} or {{integration/basic/target/test-classes/org/jboss/as/test/integration/jpa/hibernate/management}}.

Ondra

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 05:43:00 2015
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Thu, 24 Sep 2015 05:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.10615.1443087780164@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112040#comment-13112040 ] 

Michael Musgrove commented on WFLY-5261:
----------------------------------------

[~tomekadamski] This issue should be resolved now - my PR for the fix (https://issues.jboss.org/browse/WFLY-5379) has been merged

> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 05:44:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 24 Sep 2015 05:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5394) Generic acceptor/connector is
 ignoring its socket-binding
In-Reply-To: <JIRA.12585794.1443017471000@Atlassian.JIRA>
References: <JIRA.12585794.1443017471000@Atlassian.JIRA>
	<JIRA.12585794.1443017471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585794.1443017471000.10621.1443087840153@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5394:
------------------------------
    Summary: Generic acceptor/connector is ignoring its socket-binding  (was: Netty acceptor is ignored in configuration and not opened )


> Generic acceptor/connector is ignoring its socket-binding
> ---------------------------------------------------------
>
>                 Key: WFLY-5394
>                 URL: https://issues.jboss.org/browse/WFLY-5394
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> If netty acceptor is configured then port is not opened:
> {code}
> <acceptor name="netty" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory" socket-binding="messaging"/>
> {code}
> after server is started. Setting higher priority because it's core functionality.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 05:50:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 24 Sep 2015 05:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5394) Generic acceptor/connector is
 ignoring its socket-binding
In-Reply-To: <JIRA.12585794.1443017471000@Atlassian.JIRA>
References: <JIRA.12585794.1443017471000@Atlassian.JIRA>
	<JIRA.12585794.1443017471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585794.1443017471000.10633.1443088200970@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112045#comment-13112045 ] 

Jeff Mesnil commented on WFLY-5394:
-----------------------------------

[~mnovak] you were right, the socket-binding was ignored for generic acceptor/connecto resources. Thanks for spotting this out! 

> Generic acceptor/connector is ignoring its socket-binding
> ---------------------------------------------------------
>
>                 Key: WFLY-5394
>                 URL: https://issues.jboss.org/browse/WFLY-5394
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> If netty acceptor is configured then port is not opened:
> {code}
> <acceptor name="netty" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory" socket-binding="messaging"/>
> {code}
> after server is started. Setting higher priority because it's core functionality.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 05:51:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Sep 2015 05:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-293) Add file based auth to http
 management interface
In-Reply-To: <JIRA.12487616.1363783129000@Atlassian.JIRA>
References: <JIRA.12487616.1363783129000@Atlassian.JIRA>
	<JIRA.12487616.1363783129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487616.1363783129000.10646.1443088260243@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112046#comment-13112046 ] 

Darran Lofthouse commented on ELY-293:
--------------------------------------

[~maxandersen] From your perspective - nothing.  However on the server side I am moving HTTP authentication into Elytron for a closer relationship and model to how we handle SASL mechanisms so this would need to be implemented in Elytron and not WildFly.

> Add file based auth to http management interface
> ------------------------------------------------
>
>                 Key: ELY-293
>                 URL: https://issues.jboss.org/browse/ELY-293
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Max Rydahl Andersen
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha1
>
>
> usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 06:07:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Thu, 24 Sep 2015 06:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5388) Intermittent
 java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided
 undertow, resteasy, and jackson
In-Reply-To: <JIRA.12585747.1443000917000@Atlassian.JIRA>
References: <JIRA.12585747.1443000917000@Atlassian.JIRA>
	<JIRA.12585747.1443000917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585747.1443000917000.10723.1443089220258@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112058#comment-13112058 ] 

Geoffrey De Smet commented on WFLY-5388:
----------------------------------------

The stacktrace so google can index "IOException: UT010029: Stream is closed" and lead them here:

{code}
12:04:33,215 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /optaconf-webapp/rest/conference: org.jboss.resteasy.spi.UnhandledException: Response is committed, can't handle exception
	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:148)
   ...
Caused by: java.io.IOException: UT010029: Stream is closed
	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:136)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletResponseWrapper$DeferredOutputStream.write(HttpServletResponseWrapper.java:46)
	at org.jboss.resteasy.util.CommitHeaderOutputStream.write(CommitHeaderOutputStream.java:71)
	at org.jboss.resteasy.util.DelegatingOutputStream.write(DelegatingOutputStream.java:48)
	at com.fasterxml.jackson.core.json.UTF8JsonGenerator._flushBuffer(UTF8JsonGenerator.java:1846)
	at com.fasterxml.jackson.core.json.UTF8JsonGenerator.close(UTF8JsonGenerator.java:1070)
	at org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.writeTo(ResteasyJackson2Provider.java:209)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:129)
	at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:62)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:118)
	at org.jboss.resteasy.security.doseta.DigitalSigningInterceptor.aroundWriteTo(DigitalSigningInterceptor.java:143)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:122)
	at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:122)
	at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:99)
	at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:427)
	... 33 more
{code}

> Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5388
>                 URL: https://issues.jboss.org/browse/WFLY-5388
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST, Web (Undertow)
>    Affects Versions: 8.2.1.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Matyas Danter
>            Assignee: Stuart Douglas
>
> When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .
> The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 06:14:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Thu, 24 Sep 2015 06:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5388) Intermittent
 java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided
 undertow, resteasy, and jackson
In-Reply-To: <JIRA.12585747.1443000917000@Atlassian.JIRA>
References: <JIRA.12585747.1443000917000@Atlassian.JIRA>
	<JIRA.12585747.1443000917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585747.1443000917000.10745.1443089640143@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112061#comment-13112061 ] 

Geoffrey De Smet commented on WFLY-5388:
----------------------------------------

The RESTEasy reference manual mentions some pitfalls when integrating jackson 2.2.x with JBoss AS7, but because WildFly 9 already uses Jackson 2 (instead of 1 like AS7), that does not apply to this issue:
  http://docs.jboss.org/resteasy/docs/3.0.12.Final/userguide/html_single/#d4e1078

> Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5388
>                 URL: https://issues.jboss.org/browse/WFLY-5388
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST, Web (Undertow)
>    Affects Versions: 8.2.1.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Matyas Danter
>            Assignee: Stuart Douglas
>
> When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .
> The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 06:23:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 24 Sep 2015 06:23:00 -0400 (EDT)
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.10784.1443090180541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak moved JBEAP-1151 to WFLY-5400:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5400  (was: JBEAP-1151)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: JMS
                           (was: JMS)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR1
                           (was: 7.0.0.DR10)


> 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: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Clebert Suconic
>            Priority: Blocker
>         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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 06:24:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Thu, 24 Sep 2015 06:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5388) Intermittent
 java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided
 undertow, resteasy, and jackson
In-Reply-To: <JIRA.12585747.1443000917000@Atlassian.JIRA>
References: <JIRA.12585747.1443000917000@Atlassian.JIRA>
	<JIRA.12585747.1443000917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585747.1443000917000.10789.1443090240190@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112067#comment-13112067 ] 

Geoffrey De Smet commented on WFLY-5388:
----------------------------------------

Annotating this on all services does NOT FIX it either:

{code}
@org.jboss.resteasy.annotations.providers.jaxb.IgnoreMediaTypes("application/*+json")
{code}

> Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5388
>                 URL: https://issues.jboss.org/browse/WFLY-5388
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST, Web (Undertow)
>    Affects Versions: 8.2.1.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Matyas Danter
>            Assignee: Stuart Douglas
>
> When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .
> The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 07:05:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 07:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5261) Can't reload server when JTS
 transactions are used
In-Reply-To: <JIRA.12583545.1441191078000@Atlassian.JIRA>
References: <JIRA.12583545.1441191078000@Atlassian.JIRA>
	<JIRA.12583545.1441191078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583545.1441191078000.10944.1443092700222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski resolved WFLY-5261.
----------------------------------
    Fix Version/s: 10.0.0.CR2
       Resolution: Done


> Can't reload server when JTS transactions are used
> --------------------------------------------------
>
>                 Key: WFLY-5261
>                 URL: https://issues.jboss.org/browse/WFLY-5261
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Transactions
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>         Attachments: server.log, standalone-full.jts.xml
>
>
> It seems that issue WFLY-4549 was not fully fixed. The reload for the server that uses JTS transactions does not work properly. The error [1] is still shown.
> [1]
> {code}
> WARN  [com.arjuna.ats.jts] (MSC service thread 1-2) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: java.lang.NullPointerException
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.getCorbaContactInfoListFactory(ORBImpl.java:1889)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:678)
>  at com.sun.corba.se.impl.orbutil.ORBUtility.makeObjectReference(ORBUtility.java:687)
>  at com.sun.corba.se.impl.ior.ObjectReferenceProducerBase.make_object(ObjectReferenceProducerBase.java:60)
>  at com.sun.corba.se.spi.oa.ObjectAdapterBase.makeObject(ObjectAdapterBase.java:142)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.create_reference_with_id(POAImpl.java:1353)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit.startRCservice(JavaIdlRCServiceInit.java:196)
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:141)
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:102)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:226)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:145)
>  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)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 07:27:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Sep 2015 07:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4942) KeyAffinityService race
 condition on view change
In-Reply-To: <JIRA.12578289.1437053811000@Atlassian.JIRA>
References: <JIRA.12578289.1437053811000@Atlassian.JIRA>
	<JIRA.12578289.1437053811000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578289.1437053811000.10984.1443094020163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112088#comment-13112088 ] 

RH Bugzilla Integration commented on WFLY-4942:
-----------------------------------------------

Ivan Straka <istraka at redhat.com> changed the Status of [bug 1233968|https://bugzilla.redhat.com/show_bug.cgi?id=1233968] from ON_QA to VERIFIED

> KeyAffinityService race condition on view change
> ------------------------------------------------
>
>                 Key: WFLY-4942
>                 URL: https://issues.jboss.org/browse/WFLY-4942
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Bartosz Baranowski
>            Assignee: Jason Greene
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 07:39:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 24 Sep 2015 07:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5388) Intermittent
 java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided
 undertow, resteasy, and jackson
In-Reply-To: <JIRA.12585747.1443000917000@Atlassian.JIRA>
References: <JIRA.12585747.1443000917000@Atlassian.JIRA>
	<JIRA.12585747.1443000917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585747.1443000917000.11034.1443094740741@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112095#comment-13112095 ] 

Stuart Douglas commented on WFLY-5388:
--------------------------------------

This exception happens when a browser closes connection before the response is fully sent. The real bug here is that it is being logged at too high a level. 

> Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5388
>                 URL: https://issues.jboss.org/browse/WFLY-5388
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST, Web (Undertow)
>    Affects Versions: 8.2.1.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Matyas Danter
>            Assignee: Stuart Douglas
>
> When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .
> The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 07:47:00 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Sep 2015 07:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5235) CDI interceptors are not
 called when invoking observer method
In-Reply-To: <JIRA.12583196.1440938405000@Atlassian.JIRA>
References: <JIRA.12583196.1440938405000@Atlassian.JIRA>
	<JIRA.12583196.1440938405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583196.1440938405000.11046.1443095220101@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112097#comment-13112097 ] 

Martin Kouba commented on WFLY-5235:
------------------------------------

Hi Dirk, I believe the observer methods can be private. Let me check your demo code.

> CDI interceptors are not called when invoking observer method
> -------------------------------------------------------------
>
>                 Key: WFLY-5235
>                 URL: https://issues.jboss.org/browse/WFLY-5235
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 9.0.1.Final
>            Reporter: Dirk Weil
>            Assignee: Martin Kouba
>
> The following code runs with an active transaction on WFLY 8.2.0, but failes with an TransactionRequiredException on WFLY 9.0.1:
> @ApplicationScoped
> public class InitCocktailDemoDataService
> {
>   @PersistenceContext
>   private EntityManager entityManager;
>   @Transactional
>   private void createDemoData(@Observes @Initialized(ApplicationScoped.class) Object event)
>   {
>         this.entityManager.merge(someEntity);
>       }
> It seems that interceptors aren't called at all - at least for observers of scope lifecycle events.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 08:38:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Sep 2015 08:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2567) Custom authentication
 mechanism definition - Subsystem Level
In-Reply-To: <JIRA.12526043.1385388220000@Atlassian.JIRA>
References: <JIRA.12526043.1385388220000@Atlassian.JIRA>
	<JIRA.12526043.1385388220000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526043.1385388220000.11186.1443098280333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2567.
------------------------------------
    Resolution: Out of Date


Elytron will be containing a full SASL styled framework for custom HTTP authentication mechanisms combined with HTTP authentication policies to fine tune mechanism selection.

> Custom authentication mechanism definition - Subsystem Level
> ------------------------------------------------------------
>
>                 Key: WFLY-2567
>                 URL: https://issues.jboss.org/browse/WFLY-2567
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: web_security
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 08:46:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Sep 2015 08:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5401) Bump the schema and model
 version of the Undertow subsystem
In-Reply-To: <JIRA.12585958.1443098748000@Atlassian.JIRA>
References: <JIRA.12585958.1443098748000@Atlassian.JIRA>
	<JIRA.12585958.1443098748689@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585958.1443098748000.11247.1443098760176@Atlassian.JIRA>

Darran Lofthouse created WFLY-5401:
--------------------------------------

             Summary: Bump the schema and model version of the Undertow subsystem
                 Key: WFLY-5401
                 URL: https://issues.jboss.org/browse/WFLY-5401
             Project: WildFly
          Issue Type: Task
          Components: Web (Undertow)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 08:49:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Sep 2015 08:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5402) Bump the schema and model
 version for the EJB subsystem
In-Reply-To: <JIRA.12585960.1443098907000@Atlassian.JIRA>
References: <JIRA.12585960.1443098907000@Atlassian.JIRA>
	<JIRA.12585960.1443098907867@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585960.1443098907000.11253.1443098940231@Atlassian.JIRA>

Darran Lofthouse created WFLY-5402:
--------------------------------------

             Summary: Bump the schema and model version for the EJB subsystem
                 Key: WFLY-5402
                 URL: https://issues.jboss.org/browse/WFLY-5402
             Project: WildFly
          Issue Type: Task
          Components: EJB
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 08:50:00 2015
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 24 Sep 2015 08:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4971) lots of warnings discarded
 message from different cluster
In-Reply-To: <JIRA.12578665.1437430645000@Atlassian.JIRA>
References: <JIRA.12578665.1437430645000@Atlassian.JIRA>
	<JIRA.12578665.1437430645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578665.1437430645000.11259.1443099000582@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-4971:
------------------------------------

    Assignee: Paul Ferraro  (was: Jason Greene)


> lots of warnings discarded message from different cluster
> ---------------------------------------------------------
>
>                 Key: WFLY-4971
>                 URL: https://issues.jboss.org/browse/WFLY-4971
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Final
>            Reporter: Daniele Pirola
>            Assignee: Paul Ferraro
>
> I run the latest wildfly-9.0.0.Final. I have an environment with 2 host and 3 server per host. I noticed that there are a lot of warning like this
> JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee)
> or this
> JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster)
> With the same configuration in wildfly-8.2.0.Final I didn't noticed anything.
> The strange thing is that warnings still appear even if I run only the domain controller with 1 server active. I think that the domain configuration (I used the default with full-ha profile) is missing something that can diffentiate jgroup channel but I don't know how



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 08:52:00 2015
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Thu, 24 Sep 2015 08:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-293) Add file based auth to http
 management interface
In-Reply-To: <JIRA.12487616.1363783129000@Atlassian.JIRA>
References: <JIRA.12487616.1363783129000@Atlassian.JIRA>
	<JIRA.12487616.1363783129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487616.1363783129000.11274.1443099120222@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112130#comment-13112130 ] 

Max Rydahl Andersen commented on ELY-293:
-----------------------------------------

okey - gotcha.

> Add file based auth to http management interface
> ------------------------------------------------
>
>                 Key: ELY-293
>                 URL: https://issues.jboss.org/browse/ELY-293
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Max Rydahl Andersen
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha1
>
>
> usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:10:01 2015
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Thu, 24 Sep 2015 09:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-927) Persistence tests don't
 support Postgres Plus
In-Reply-To: <JIRA.12585967.1443100195000@Atlassian.JIRA>
References: <JIRA.12585967.1443100195000@Atlassian.JIRA>
	<JIRA.12585967.1443100195392@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585967.1443100195000.11391.1443100201279@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-927:
------------------------------------

             Summary: Persistence tests don't support Postgres Plus
                 Key: DROOLS-927
                 URL: https://issues.jboss.org/browse/DROOLS-927
             Project: Drools
          Issue Type: Feature Request
            Reporter: Tibor Zim?nyi
            Assignee: Mark Proctor
            Priority: Minor


In drools-persistence-jpa module in PersistenceUtil, there is a method setupPoolingDataSource which sets up data source properties based on JDBC driver class. This method should be also aware of Postgres Plus driver, because it is also a supported database system.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 09:12:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 24 Sep 2015 09:12:00 -0400 (EDT)
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.11396.1443100320242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-2554.
-------------------------------
    Resolution: Done


I think we can safely call this "solved" at this point; at least, no further benefit arises from having a tracked issue for it.

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:13:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 24 Sep 2015 09:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1525) Filesystem JAR permission
	processing
In-Reply-To: <JIRA.12494245.1371164451000@Atlassian.JIRA>
References: <JIRA.12494245.1371164451000@Atlassian.JIRA>
	<JIRA.12494245.1371164451000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494245.1371164451000.11400.1443100380207@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-1525.
-------------------------------
    Fix Version/s: 8.0.0.Final
                       (was: 10.0.0.CR2)
         Assignee: Stefan Guilhen
       Resolution: Done


I recall that Stefan had this working by 8.0.0.Final.

> Filesystem JAR permission processing
> ------------------------------------
>
>                 Key: WFLY-1525
>                 URL: https://issues.jboss.org/browse/WFLY-1525
>             Project: WildFly
>          Issue Type: Task
>          Components: Security Manager
>            Reporter: David Lloyd
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.Final
>
>
> Parse {{jboss-permission.xml}} files found in filesystem and (old-style) extension JARs to establish their base permission set.  If no such file is found then default to the minimal permission set.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:14:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 09:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5403) Adapt EJB3 subsystem to the
 new ejb client library
In-Reply-To: <JIRA.12585969.1443100411000@Atlassian.JIRA>
References: <JIRA.12585969.1443100411000@Atlassian.JIRA>
	<JIRA.12585969.1443100411860@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585969.1443100411000.11403.1443100440174@Atlassian.JIRA>

Tomasz Adamski created WFLY-5403:
------------------------------------

             Summary: Adapt EJB3 subsystem to the new ejb client library
                 Key: WFLY-5403
                 URL: https://issues.jboss.org/browse/WFLY-5403
             Project: WildFly
          Issue Type: Enhancement
          Components: EJB
    Affects Versions: 10.0.0.CR1
            Reporter: Tomasz Adamski
            Assignee: Tomasz Adamski






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:15:03 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 24 Sep 2015 09:15:03 -0400 (EDT)
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.11411.1443100503312@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-473.
------------------------------
    Fix Version/s:     (was: 10.0.0.CR2)
       Resolution: Done


This was resolved some time ago.

> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:15:03 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 24 Sep 2015 09:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-680) Discontinue VFS
In-Reply-To: <JIRA.12570939.1430942952000@Atlassian.JIRA>
References: <JIRA.12570939.1430942952000@Atlassian.JIRA>
	<JIRA.12570939.1430942952000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570939.1430942952000.11416.1443100503473@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFCORE-680:
----------------------------------

    Assignee: Richard Opalka


> Discontinue VFS
> ---------------
>
>                 Key: WFCORE-680
>                 URL: https://issues.jboss.org/browse/WFCORE-680
>             Project: WildFly Core
>          Issue Type: Task
>          Components: VFS
>            Reporter: David Lloyd
>            Assignee: Richard Opalka
>
> Due to various design and implementation problems, especially on Windows, we should discontinue VFS.  It could be replaced by the following:
> * URL handlers:
> ** A "deployment" URL handler which could possibly use standard {{\!/}} syntax (but extended to arbitrary levels) to identify nested JARs, like this: {{deployment:/myApp.ear!/lib/someThing.jar!/org/foo/Bar.class}}
> ** An "ext" URL handler which would identify extensions by name: {{ext:/my-extension/org/foo/Bar.class}}
> ** Normal {{jar}} URLs for filesystem JARs
> * The URL handlers should use a "current application server" context selector in order to convert the global ref into an AS instance-relative ref, as we should not be maintaining global state
> * Separate module loaders (and services, if appropriate) for the above three cases, whose class loaders in turn use the above URL schemes (as appropriate) for code source and resource URLs



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:15:03 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 09:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5403) Adapt EJB3 subsystem to the
 new ejb client library
In-Reply-To: <JIRA.12585969.1443100411000@Atlassian.JIRA>
References: <JIRA.12585969.1443100411000@Atlassian.JIRA>
	<JIRA.12585969.1443100411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585969.1443100411000.11419.1443100503577@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski updated WFLY-5403:
---------------------------------
    Description: EJB3 subsystem has to be adopted to the new jboss-ejb-client library.


> Adapt EJB3 subsystem to the new ejb client library
> --------------------------------------------------
>
>                 Key: WFLY-5403
>                 URL: https://issues.jboss.org/browse/WFLY-5403
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EJB
>    Affects Versions: 10.0.0.CR1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>
> EJB3 subsystem has to be adopted to the new jboss-ejb-client library.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:20:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 09:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@Atlassian.JIRA>
References: <JIRA.12509159.1383210125000@Atlassian.JIRA>
	<JIRA.12509159.1383210125000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.11458.1443100800632@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112151#comment-13112151 ] 

Tomasz Adamski commented on WFLY-2422:
--------------------------------------

I'm currently making the changes to the EJB3 subsystem to adapt it to the new features provided in the new jboss-ejb-client library. Part of those changes is related to the profile concept and will result in more convenient and simple configuration. Nevertheless, because the task is wider in scope - I have decided to create another JIRA for it https://issues.jboss.org/browse/WFLY-5403.

> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFLY-2422
>                 URL: https://issues.jboss.org/browse/WFLY-2422
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:21:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Sep 2015 09:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1006) Upgrade to PicketBox 5
In-Reply-To: <JIRA.12585975.1443100813000@Atlassian.JIRA>
References: <JIRA.12585975.1443100813000@Atlassian.JIRA>
	<JIRA.12585975.1443100813871@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585975.1443100813000.11462.1443100860333@Atlassian.JIRA>

Darran Lofthouse created WFCORE-1006:
----------------------------------------

             Summary: Upgrade to PicketBox 5
                 Key: WFCORE-1006
                 URL: https://issues.jboss.org/browse/WFCORE-1006
             Project: WildFly Core
          Issue Type: Component  Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Stefan Guilhen
             Fix For: 3.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:22:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 09:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@Atlassian.JIRA>
References: <JIRA.12509159.1383210125000@Atlassian.JIRA>
	<JIRA.12509159.1383210125000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.11483.1443100920710@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112151#comment-13112151 ] 

Tomasz Adamski edited comment on WFLY-2422 at 9/24/15 9:21 AM:
---------------------------------------------------------------

I'm currently making the changes to the EJB3 subsystem to adapt it to the new features provided in the new jboss-ejb-client library. Part of those changes is related to the profile concept and will result in more convenient and simple configuration. Nevertheless, because the task is wider in scope - I have decided to create another JIRA for it WFLY-5403.


was (Author: tomekadamski):
I'm currently making the changes to the EJB3 subsystem to adapt it to the new features provided in the new jboss-ejb-client library. Part of those changes is related to the profile concept and will result in more convenient and simple configuration. Nevertheless, because the task is wider in scope - I have decided to create another JIRA for it https://issues.jboss.org/browse/WFLY-5403.

> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFLY-2422
>                 URL: https://issues.jboss.org/browse/WFLY-2422
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:22:01 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 09:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@Atlassian.JIRA>
References: <JIRA.12509159.1383210125000@Atlassian.JIRA>
	<JIRA.12509159.1383210125000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.11503.1443100921122@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112151#comment-13112151 ] 

Tomasz Adamski edited comment on WFLY-2422 at 9/24/15 9:21 AM:
---------------------------------------------------------------

I'm currently making the changes to the EJB3 subsystem to adapt it to the new features provided in the new jboss-ejb-client library. Part of those changes is related to the profile concept and will result in more convenient and simple configuration. Nevertheless, because the task is wider in scope - I have decided to create another JIRA for it: WFLY-5403.


was (Author: tomekadamski):
I'm currently making the changes to the EJB3 subsystem to adapt it to the new features provided in the new jboss-ejb-client library. Part of those changes is related to the profile concept and will result in more convenient and simple configuration. Nevertheless, because the task is wider in scope - I have decided to create another JIRA for it WFLY-5403.

> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFLY-2422
>                 URL: https://issues.jboss.org/browse/WFLY-2422
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:23:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Sep 2015 09:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1006) Upgrade to PicketBox 5
In-Reply-To: <JIRA.12585975.1443100813000@Atlassian.JIRA>
References: <JIRA.12585975.1443100813000@Atlassian.JIRA>
	<JIRA.12585975.1443100813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585975.1443100813000.11509.1443100980256@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112155#comment-13112155 ] 

Darran Lofthouse commented on WFCORE-1006:
------------------------------------------

For now just so we have an issue we can reference in the PicketBox upgrades.

> Upgrade to PicketBox 5
> ----------------------
>
>                 Key: WFCORE-1006
>                 URL: https://issues.jboss.org/browse/WFCORE-1006
>             Project: WildFly Core
>          Issue Type: Component  Upgrade
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Stefan Guilhen
>             Fix For: 3.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:26:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 24 Sep 2015 09:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase
 fails consistently
In-Reply-To: <JIRA.12562786.1423556666000@Atlassian.JIRA>
References: <JIRA.12562786.1423556666000@Atlassian.JIRA>
	<JIRA.12562786.1423556666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562786.1423556666000.11532.1443101160431@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-4334:
---------------------------------

    Assignee:     (was: David Lloyd)


> CalendarBasedTimeoutTestCase fails consistently
> -----------------------------------------------
>
>                 Key: WFLY-4334
>                 URL: https://issues.jboss.org/browse/WFLY-4334
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Thomas Diesler
>
> Happens on branch 8.x
> {code}
> Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase)  Time elapsed: 0.342 sec  <<< FAILURE!
> java.lang.AssertionError: Eastern European Time
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539)
> 	at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:27:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Sep 2015 09:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4971) lots of warnings discarded
 message from different cluster
In-Reply-To: <JIRA.12578665.1437430645000@Atlassian.JIRA>
References: <JIRA.12578665.1437430645000@Atlassian.JIRA>
	<JIRA.12578665.1437430645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578665.1437430645000.11550.1443101220783@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-4971.
------------------------------
    Resolution: Duplicate Issue


Duplicated by https://issues.jboss.org/browse/WFLY-5189
Essentially, there are 2 ways to address this:
1. Migrate messaging-activemq to use the default channel of the server, by default.
2. Set JGroups stack transport's log_discard_msgs property to false

> lots of warnings discarded message from different cluster
> ---------------------------------------------------------
>
>                 Key: WFLY-4971
>                 URL: https://issues.jboss.org/browse/WFLY-4971
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Final
>            Reporter: Daniele Pirola
>            Assignee: Paul Ferraro
>
> I run the latest wildfly-9.0.0.Final. I have an environment with 2 host and 3 server per host. I noticed that there are a lot of warning like this
> JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee)
> or this
> JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster)
> With the same configuration in wildfly-8.2.0.Final I didn't noticed anything.
> The strange thing is that warnings still appear even if I run only the domain controller with 1 server active. I think that the domain configuration (I used the default with full-ha profile) is missing something that can diffentiate jgroup channel but I don't know how



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:28:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 24 Sep 2015 09:28:00 -0400 (EDT)
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.11585.1443101280213@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112168#comment-13112168 ] 

Amos Feng commented on WFLY-5100:
---------------------------------

Thanks Ondra, I will take a look at it.

For fixing the issue, it needs to upgrade the narayana version to 5.2.5.Final which contains the fix of JBTM-2523

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.CR2
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 09:30:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Sep 2015 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase
 fails consistently
In-Reply-To: <JIRA.12562786.1423556666000@Atlassian.JIRA>
References: <JIRA.12562786.1423556666000@Atlassian.JIRA>
	<JIRA.12562786.1423556666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562786.1423556666000.11591.1443101400477@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-4334.
-----------------------------
    Fix Version/s: 9.0.0.Final
       Resolution: Rejected


> CalendarBasedTimeoutTestCase fails consistently
> -----------------------------------------------
>
>                 Key: WFLY-4334
>                 URL: https://issues.jboss.org/browse/WFLY-4334
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Thomas Diesler
>             Fix For: 9.0.0.Final
>
>
> Happens on branch 8.x
> {code}
> Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase)  Time elapsed: 0.342 sec  <<< FAILURE!
> java.lang.AssertionError: Eastern European Time
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539)
> 	at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:51:00 2015
From: issues at jboss.org (Dominik Pospisil (JIRA))
Date: Thu, 24 Sep 2015 09:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5180) InfinispanResourceRefTestCase
 causes NameNotFoundException with security manager
In-Reply-To: <JIRA.12582304.1440412830000@Atlassian.JIRA>
References: <JIRA.12582304.1440412830000@Atlassian.JIRA>
	<JIRA.12582304.1440412830000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582304.1440412830000.11744.1443102660912@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112185#comment-13112185 ] 

Dominik Pospisil commented on WFLY-5180:
----------------------------------------

The reason of the failure is that the org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanBean is creating a new cache in @PostConstruct:

this.cache = this.container.getCache();

If I change the InfinispanBean so that the cache is injected via the web.xml the way the container is the issue is gone.

The question is do we support creating caches from user code? If yes, it needs to be executed in a priviledged code (at least part of).

> InfinispanResourceRefTestCase causes NameNotFoundException with security manager
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5180
>                 URL: https://issues.jboss.org/browse/WFLY-5180
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Paul Ferraro
>
> *Description of problem:*
> InfinispanResourceRefTestCase causes NameNotFoundException with security manager.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./build.sh -DskipTests -DallTests -Dts.noSmoke
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=InfinispanResourceRefTestCase
> *Actual results:*
> {noformat}
> javax.naming.NameNotFoundException: infinispan
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	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: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.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase.test(InfinispanResourceRefTestCase.java:64)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 09:58:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Sep 2015 09:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5371) Stock configuration for
 ActiveMQ should specify a JGroups channel instead of a stack
In-Reply-To: <JIRA.12585414.1442602571000@Atlassian.JIRA>
References: <JIRA.12585414.1442602571000@Atlassian.JIRA>
	<JIRA.12585414.1442602571000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585414.1442602571000.11818.1443103080550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-5371.
------------------------------
    Resolution: Duplicate Issue


Duplicate of WFLY-5189.

> Stock configuration for ActiveMQ should specify a JGroups channel instead of a stack
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-5371
>                 URL: https://issues.jboss.org/browse/WFLY-5371
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Rich DiCroce
>            Assignee: Jeff Mesnil
>
> The stock configuration specifies jgroups-stack="udp" in the messaging-activemq subsystem. This appears to cause a second instance of that stack to be created if other subsystems (e.g. Infinispan) are also using it. That second instance appears to cause WFLY-4971.
> WildFly still seems happy if I change the jgroups-stack to "ee" (to use the ee channel) or to a fork off the ee channel. The stock configuration should do the same thing to fix WFLY-4971.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:58:00 2015
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 24 Sep 2015 09:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-919) Release PicketBox
	5.0.0.Alpha2
In-Reply-To: <JIRA.12585984.1443103042000@Atlassian.JIRA>
References: <JIRA.12585984.1443103042000@Atlassian.JIRA>
	<JIRA.12585984.1443103042708@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585984.1443103042000.11820.1443103080595@Atlassian.JIRA>

Stefan Guilhen created SECURITY-919:
---------------------------------------

             Summary: Release PicketBox 5.0.0.Alpha2
                 Key: SECURITY-919
                 URL: https://issues.jboss.org/browse/SECURITY-919
             Project: PicketBox 
          Issue Type: Release
          Components: JBossSX, Security SPI
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 09:59:00 2015
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 24 Sep 2015 09:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-903) Differently implemented
 password-stacking option in ClientLoginModule
In-Reply-To: <JIRA.12581986.1440074055000@Atlassian.JIRA>
References: <JIRA.12581986.1440074055000@Atlassian.JIRA>
	<JIRA.12581986.1440074055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581986.1440074055000.11826.1443103140146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen updated SECURITY-903:
------------------------------------
    Fix Version/s: PicketBox_5_0_0.Alpha2
                       (was: PicketBox_5_0_0.Beta1)


> Differently implemented password-stacking option in ClientLoginModule
> ---------------------------------------------------------------------
>
>                 Key: SECURITY-903
>                 URL: https://issues.jboss.org/browse/SECURITY-903
>             Project: PicketBox 
>          Issue Type: Bug
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: PicketBox_5_0_0.Alpha2
>
>
> From BZ:
> "In case when some login module should use password stacking then value of password-stacking option should be set to useFirstPass. All login modules should respect it. However implemetation of org.jboss.security.ClientLoginModule uses password-stacking differently - it uses password stacking everytime when some value is set for password-stacking option (even value false). It should work same as other login modules. Current behavior can be confusing and can lead to incorrectly set server configuration."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 10:19:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Sep 2015 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.12003.1443104340706@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112213#comment-13112213 ] 

Paul Ferraro commented on WFLY-5358:
------------------------------------

See https://issues.jboss.org/browse/JGRP-1826

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 10:22:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Sep 2015 10:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.12038.1443104520721@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-5290:
-------------------------------
    Workaround Description: 
The address of the transport changed in WF9.  The workaround is to use the new address of the transport, not the legacy address, e.g. /subsystem=jgroups/stack=foo/transport=UDP



> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 10:23:00 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Thu, 24 Sep 2015 10:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently. Allow idle thread reusage.
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.12050.1443104580581@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
    Attachment: JBossThreadPoolReuseIdleThreadsExecutor.jpg
                JBossThreadPoolExecutor.jpg


Files of the state diagrams of JBossThreadPoolExecutor that is used at the point and JBossThreadPoolReuseIdleThreadsExecutor that is proposed.

> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>         Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new 
> thread [up until max-threads]."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 10:25:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Sep 2015 10:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.12067.1443104700403@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112220#comment-13112220 ] 

Paul Ferraro commented on WFLY-5290:
------------------------------------

[~kabirkhan] I'm convinced that this is not a clustering specific issue but rather a general issue with resource aliases and add operations.  It seems that the alias is not resolving because no such attribute exists at the target address - and there won't be, because this is an add operation.

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 10:26:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Sep 2015 10:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.12078.1443104760276@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112220#comment-13112220 ] 

Paul Ferraro edited comment on WFLY-5290 at 9/24/15 10:25 AM:
--------------------------------------------------------------

[~kabirkhan] [~brian.stansberry] I'm convinced that this is not a clustering specific issue but rather a general issue with resource aliases and add operations.  It seems that the alias is not resolving because no such attribute exists at the target address - and there won't be, because this is an add operation.


was (Author: pferraro):
[~kabirkhan] I'm convinced that this is not a clustering specific issue but rather a general issue with resource aliases and add operations.  It seems that the alias is not resolving because no such attribute exists at the target address - and there won't be, because this is an add operation.

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 10:36:00 2015
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 24 Sep 2015 10:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-919) Release PicketBox
	5.0.0.Alpha2
In-Reply-To: <JIRA.12585984.1443103042000@Atlassian.JIRA>
References: <JIRA.12585984.1443103042000@Atlassian.JIRA>
	<JIRA.12585984.1443103042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585984.1443103042000.12097.1443105360226@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed SECURITY-919.
-----------------------------------
    Resolution: Done


PicketBox 5.0.0.Alpha2 has been released

> Release PicketBox 5.0.0.Alpha2
> ------------------------------
>
>                 Key: SECURITY-919
>                 URL: https://issues.jboss.org/browse/SECURITY-919
>             Project: PicketBox 
>          Issue Type: Release
>          Components: JBossSX, Security SPI
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 10:38:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 10:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5399) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.12108.1443105480220@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112225#comment-13112225 ] 

Brian Stansberry commented on WFLY-5399:
----------------------------------------

I predict is this is due to WFLY-5306. The extension is removed in the course of the op, which means by the time the notifications are emitted at the end of the op the entire API for the extension is gone.

> :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5399
>                 URL: https://issues.jboss.org/browse/WFLY-5399
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Brian Stansberry
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 10:54:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 10:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5399) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.12168.1443106440464@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112236#comment-13112236 ] 

Brian Stansberry commented on WFLY-5399:
----------------------------------------

Three possible solutions:

1) Revert WLFY-5306. But that's not a true solution, as a user could create a composite op that removes a subsystem and then drops the extension in the final step, and they'd get the same behavior.

2) Move the validation to when the notification is registered (OperationContext.emit()) instead of when the OC sends it out. At that point the resource registration should still be there.

3) Change the validation logic to check whether the resource registration still exists when it finds undescribed notifications; if not assume the op has removed the previously existing notification.

#2 sounds like the cleanest solution; I'll just check with [~jmesnil] about whether there is any reason we needed to defer the validation. I also want to discuss whether sending out a notification for a no-longer existing resource might cause a problem. The current validation logic isn't preventing sending out the notification though; all it does is log the WARN. So continuing to send them out will not be a behavior change.


> :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5399
>                 URL: https://issues.jboss.org/browse/WFLY-5399
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Brian Stansberry
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 11:04:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 24 Sep 2015 11:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-924) EventFactHandles are not
 deserialized correctly
In-Reply-To: <JIRA.12585402.1442592215000@Atlassian.JIRA>
References: <JIRA.12585402.1442592215000@Atlassian.JIRA>
	<JIRA.12585402.1442592215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585402.1442592215000.12197.1443107040194@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112242#comment-13112242 ] 

Mario Fusco commented on DROOLS-924:
------------------------------------

This commit is also necessary https://github.com/droolsjbpm/drools/commit/dc52d8790

> EventFactHandles are not deserialized correctly
> -----------------------------------------------
>
>                 Key: DROOLS-924
>                 URL: https://issues.jboss.org/browse/DROOLS-924
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> EventFactHandle overrides DefaultFactHandle's toExternalForm(), but it is not happening the same for the createFromExternalFormat() method. Moreover no code takes care of the 1st argument (the format version) of the serialized format so when deserializing it always instance a DefaultFactHandle even when it was serialized an event.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 11:14:00 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Thu, 24 Sep 2015 11:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently. Allow idle thread reusage.
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.12217.1443107640162@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112217#comment-13112217 ] 

Panagiotis Sotiropoulos edited comment on WFLY-5332 at 9/24/15 11:13 AM:
-------------------------------------------------------------------------

Files of the flow diagrams of JBossThreadPoolExecutor that is used at the point and JBossThreadPoolReuseIdleThreadsExecutor that is proposed.


was (Author: takis):
Files of the state diagrams of JBossThreadPoolExecutor that is used at the point and JBossThreadPoolReuseIdleThreadsExecutor that is proposed.

> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>         Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new 
> thread [up until max-threads]."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 11:24:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 24 Sep 2015 11:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5399) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.12248.1443108240170@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112245#comment-13112245 ] 

Jeff Mesnil commented on WFLY-5399:
-----------------------------------

I agree that #2 is the cleanest solution.

We should not need to make a extra case for the "removed" notification as long as we check that the resource describes the notifications when there is a resource to act upon.

The reason the notifications descriptions are checked at the end of the action was to ensure that we only do the check for actions that are successful. I did not want to have WARN about missing notifications descriptions for an operation that rolls back anyway.
However, I have no problem to change that as this issue is more "visible" by having a well described resource logging _false_ warnings when the operation is successful.

By changing the code to #2, the description of the notification will be checked when the resource description is still valid and the notifications will still be sent as expected.
Warning about undescribed notifications must not prevent the notifications to actually be emitted.

> :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5399
>                 URL: https://issues.jboss.org/browse/WFLY-5399
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Brian Stansberry
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 11:27:00 2015
From: issues at jboss.org (Marko Strukelj (JIRA))
Date: Thu, 24 Sep 2015 11:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5404) WF 10.0.0.CR2 with
 standalone.xml from WF 9 crashes on war deploy
In-Reply-To: <JIRA.12586005.1443108379000@Atlassian.JIRA>
References: <JIRA.12586005.1443108379000@Atlassian.JIRA>
	<JIRA.12586005.1443108379141@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586005.1443108379000.12254.1443108420097@Atlassian.JIRA>

Marko Strukelj created WFLY-5404:
------------------------------------

             Summary: WF 10.0.0.CR2 with standalone.xml from WF 9 crashes on war deploy
                 Key: WFLY-5404
                 URL: https://issues.jboss.org/browse/WFLY-5404
             Project: WildFly
          Issue Type: Bug
          Components: Batch
    Affects Versions: 10.0.0.CR1
            Reporter: Marko Strukelj
            Assignee: Cheng Fang


As I understand it Wildfly 10 wants to maintain configuration compatibility with Wildfly 9.
It looks lake some of the compatibility was broken with CR1 (worked with Betas). 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 11:35:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 24 Sep 2015 11:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5399) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.12285.1443108900640@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-5399:
---------------------------------

    Assignee: Jeff Mesnil  (was: Brian Stansberry)


> :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5399
>                 URL: https://issues.jboss.org/browse/WFLY-5399
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jeff Mesnil
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 11:36:01 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 24 Sep 2015 11:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1007) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.12315.1443108961511@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved WFLY-5399 to WFCORE-1007:
-------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-1007  (was: WFLY-5399)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s:     (was: 10.0.0.CR1)


> :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1007
>                 URL: https://issues.jboss.org/browse/WFCORE-1007
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jeff Mesnil
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 11:37:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 24 Sep 2015 11:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1007) :migrate operation shows
 warning "WFLYCTL0357: Notification of type resource-removed is not
 described" in log
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.12324.1443109020414@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFCORE-1007:
--------------------------------
    Affects Version/s: 2.0.0.CR4


> :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1007
>                 URL: https://issues.jboss.org/browse/WFCORE-1007
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR4
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jeff Mesnil
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 11:39:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 24 Sep 2015 11:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5404) WF 10.0.0.CR2 with
 standalone.xml from WF 9 crashes on war deploy
In-Reply-To: <JIRA.12586005.1443108379000@Atlassian.JIRA>
References: <JIRA.12586005.1443108379000@Atlassian.JIRA>
	<JIRA.12586005.1443108379000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586005.1443108379000.12334.1443109140224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFLY-5404:
-----------------------------------

    Assignee: James Perkins  (was: Cheng Fang)


> WF 10.0.0.CR2 with standalone.xml from WF 9 crashes on war deploy
> -----------------------------------------------------------------
>
>                 Key: WFLY-5404
>                 URL: https://issues.jboss.org/browse/WFLY-5404
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 10.0.0.CR1
>            Reporter: Marko Strukelj
>            Assignee: James Perkins
>
> As I understand it Wildfly 10 wants to maintain configuration compatibility with Wildfly 9.
> It looks lake some of the compatibility was broken with CR1 (worked with Betas). 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 12:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 12:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.12511.1443112080348@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112269#comment-13112269 ] 

Brian Stansberry commented on WFLY-5290:
----------------------------------------

[~pferraro] Can you point to a particular place in the code? Your last comment reads like you've found one.

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 12:41:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 24 Sep 2015 12:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.12541.1443112860476@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112273#comment-13112273 ] 

David Lloyd commented on WFCORE-756:
------------------------------------

This should be properly fixed now.  If not, let's discuss further.

> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>         Attachments: server.log, server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 13:04:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Sep 2015 13:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-742) Unify linux and PowerShell
 scripts for jboss-cli in printing environment information
In-Reply-To: <JIRA.12574035.1433506962000@Atlassian.JIRA>
References: <JIRA.12574035.1433506962000@Atlassian.JIRA>
	<JIRA.12574035.1433506962000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574035.1433506962000.12637.1443114240269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-742:
-------------------------------
    Fix Version/s: 2.0.0.CR5


> Unify linux and PowerShell scripts for jboss-cli in printing environment information
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-742
>                 URL: https://issues.jboss.org/browse/WFCORE-742
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR5
>
>
> Powershell script jboss-cli.ps1 prints environment information. 
> *Steps to Reproduce:*
> # .\jboss-cli.ps1
> *Actual results:*
> {noformat}
> =========================================================================
>   WildFly Bootstrap Environment
>   JBOSS_HOME: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0
>   JBOSS_BASE_DIR: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0\standalone
>   JAVA: java
>   JAVA_OPTS: -Xms64M -Xmx512M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.ne
> t.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman
>   JBOSS_MODULEPATH: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0\modules
> =========================================================================
> 10:22:33,569 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 10:22:33,959 INFO  [org.jboss.as.cli.CommandContext] (main) You are disconnected at the moment. Type 'connect' to connec
> t to the server or 'help' for the list of supported commands.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands
> .
> [disconnected /]
> {noformat}
> *Expected results:*
> {noformat}
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] 
> {noformat}
> \\
> \\
> ".\jboss-cli.ps1 --help" show too much logging information:
> *Steps to Reproduce:*
> # .\jboss-cli.ps1 --help
> *Actual results:*
> {noformat}
> ...
> 10:29:18,212 INFO  [org.jboss.as.cli.CommandContext] (main) Usage:
> Usage:
> 10:29:18,215 INFO  [org.jboss.as.cli.CommandContext] (main)
> 10:29:18,216 INFO  [org.jboss.as.cli.CommandContext] (main)   jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
>   jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> ...
> {noformat}
> *Expected results:*
> {noformat}
> Usage:
>   jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 13:04:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Sep 2015 13:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-744) Unify add-user script
 functionality in windows (powershell, bat) and linux
In-Reply-To: <JIRA.12574037.1433506978000@Atlassian.JIRA>
References: <JIRA.12574037.1433506978000@Atlassian.JIRA>
	<JIRA.12574037.1433506978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574037.1433506978000.12641.1443114240346@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-744:
-------------------------------
    Fix Version/s: 2.0.0.CR5


> Unify add-user script functionality in windows (powershell, bat) and linux
> --------------------------------------------------------------------------
>
>                 Key: WFCORE-744
>                 URL: https://issues.jboss.org/browse/WFCORE-744
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR5
>
>
> PowerShell scripts "add-user.ps1" is missing in EAP 7, "add-user.bat" and "add-user.sh" are in JBOSS_HOME/bin. If user is able to "add new user" by add-user.bat or add-user.sh, user should be also able to "add new user" with add-user.ps1



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 13:04:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Sep 2015 13:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-737) PowerShell script
	"vault.ps1" is missing
In-Reply-To: <JIRA.12574019.1433504541000@Atlassian.JIRA>
References: <JIRA.12574019.1433504541000@Atlassian.JIRA>
	<JIRA.12574019.1433504541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574019.1433504541000.12645.1443114240423@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-737:
-------------------------------
    Fix Version/s: 2.0.0.CR5


> PowerShell script "vault.ps1" is missing
> ----------------------------------------
>
>                 Key: WFCORE-737
>                 URL: https://issues.jboss.org/browse/WFCORE-737
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR5
>
>
> PowerShell scripts "vault.ps1" should be in JBOSS_HOME/bin



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 13:05:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Sep 2015 13:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-745) Standalone powershell script
 does't support --debug and -secmgr option
In-Reply-To: <JIRA.12574041.1433507267000@Atlassian.JIRA>
References: <JIRA.12574041.1433507267000@Atlassian.JIRA>
	<JIRA.12574041.1433507267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574041.1433507267000.12649.1443114300169@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-745:
-------------------------------
    Fix Version/s: 2.0.0.CR5


> Standalone powershell script does't support --debug and -secmgr option
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-745
>                 URL: https://issues.jboss.org/browse/WFCORE-745
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR5
>
>
> Standalone powershell script does't support --debug option. Also -secmgr option and SECMGR=true environment variable settings is missing in posershell script. 
> *Steps to Reproduce:*
> # .\standalone.ps1 --debug
> *Actual results:*
> Debug mode is not active
> *Expected results:*
> {noformat}
> ...
> Listening for transport dt_socket at address: 8787
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 13:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 13:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1008) Treat ":shutdown" requests
 similarly to ":reload" in the server-side operation handler
In-Reply-To: <JIRA.12586026.1443116399000@Atlassian.JIRA>
References: <JIRA.12586026.1443116399000@Atlassian.JIRA>
	<JIRA.12586026.1443116399840@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586026.1443116399000.12755.1443116400705@Atlassian.JIRA>

Brian Stansberry created WFCORE-1008:
----------------------------------------

             Summary: Treat ":shutdown" requests similarly to ":reload" in the server-side operation handler
                 Key: WFCORE-1008
                 URL: https://issues.jboss.org/browse/WFCORE-1008
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry


ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services.

A ":shutdown" op has similar effects to a ":reload" so there is no reason to treat it differently.

(Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.) 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 13:55:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 13:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1009) Treat intra-domain
 transactional ":reload" and ":shutdown" requests similarly to how we handle
 end user requests
In-Reply-To: <JIRA.12586028.1443117252000@Atlassian.JIRA>
References: <JIRA.12586028.1443117252000@Atlassian.JIRA>
	<JIRA.12586028.1443117252878@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586028.1443117252000.12785.1443117300076@Atlassian.JIRA>

Brian Stansberry created WFCORE-1009:
----------------------------------------

             Summary: Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests
                 Key: WFCORE-1009
                 URL: https://issues.jboss.org/browse/WFCORE-1009
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry


ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services. WFCORE-1008 proposes expanding this to the ":shutdown" operation as well.

This JIRA proposes expanding this to the TransactionalProtocolOperationHandler used for intra-domain process requests as well.

The implementation here would be slightly different in that the response to the prepared notification from the op would be unchanged. What would change would be the handling of the tx commit coming from the client. The tx commit message handling would send the response instead of waiting for the original op to complete.

The client side state related to the status of the reloading/shutting down slave HC or server should be fine. A master HC's tracking of slaves is unaffected by proxying a reload or shutdown op; it monitors the master<->slave comm channel to track the slave. Same thing for an HC reloading a server. For the case where an HC is stopping a server by sending a ":shutdown" request, the response to the request puts the HC's view of the server's state into InternalState.PROCESS_STOPPING. This state is valid as soon as the HC commits the ":shutdown" request, so this JIRA is consistent with that handling.

(Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 14:04:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 24 Sep 2015 14:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.12809.1443117840174@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112304#comment-13112304 ] 

James Perkins commented on WFLY-3990:
-------------------------------------

We've decided to back peddle a bit on default values. The way this will work now is the {{core-threads}} attribute is now nullable. If the value is left null then the number of {{core-threads}} is calculated based on the number of processors. If the {{queue-length}} is left null then the value will be set to {{Integer.MAX_VALUE}}. With the defaults this should act like an unbounded queue.

> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE, EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>            Assignee: James Perkins
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 14:11:00 2015
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Thu, 24 Sep 2015 14:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1010) standalone.sh hard codes
	boot log
In-Reply-To: <JIRA.12586032.1443118216000@Atlassian.JIRA>
References: <JIRA.12586032.1443118216000@Atlassian.JIRA>
	<JIRA.12586032.1443118216146@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586032.1443118216000.12831.1443118260187@Atlassian.JIRA>

Philippe Marschall created WFCORE-1010:
------------------------------------------

             Summary: standalone.sh hard codes boot log
                 Key: WFCORE-1010
                 URL: https://issues.jboss.org/browse/WFCORE-1010
             Project: WildFly Core
          Issue Type: Patch
          Components: Scripts
            Reporter: Philippe Marschall
            Assignee: Tomaz Cerar


The {{standalone.sh}} file hard codes the {{org.jboss.boot.log.file}} property to {{server.log}}. This is inconvenient because it overrides the dynamic configuration in {{logging.properties}} which is set to ${org.jboss.boot.log.file:boot.log}. Maybe the value in logging.properties should instead default to {{server.log}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 14:22:00 2015
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Thu, 24 Sep 2015 14:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1011) jboss-cli.ps1 uses wrong
 logging.properties
In-Reply-To: <JIRA.12586035.1443118891000@Atlassian.JIRA>
References: <JIRA.12586035.1443118891000@Atlassian.JIRA>
	<JIRA.12586035.1443118891738@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586035.1443118891000.12867.1443118920108@Atlassian.JIRA>

Philippe Marschall created WFCORE-1011:
------------------------------------------

             Summary: jboss-cli.ps1 uses wrong logging.properties
                 Key: WFCORE-1011
                 URL: https://issues.jboss.org/browse/WFCORE-1011
             Project: WildFly Core
          Issue Type: Patch
          Components: Scripts
            Reporter: Philippe Marschall
            Assignee: Tomaz Cerar


jboss-cli.ps1 uses logging.properties but should use jboss-cli-logging.properties



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 14:39:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 24 Sep 2015 14:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1010) standalone.sh hard codes
	boot log
In-Reply-To: <JIRA.12586032.1443118216000@Atlassian.JIRA>
References: <JIRA.12586032.1443118216000@Atlassian.JIRA>
	<JIRA.12586032.1443118216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586032.1443118216000.12900.1443119940109@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112314#comment-13112314 ] 

James Perkins commented on WFCORE-1010:
---------------------------------------

It should be {{server.log}} and not {{boot.log}}. That said the script should override it so that it ends up in the correct directory. Leaving the {{-Dorg.jboss.boot.log.file}} property off will end up defaulting to the {{server.log}} to the current directory not the {{$JBOSS_HOME/standalone/log}} directory.

> standalone.sh hard codes boot log
> ---------------------------------
>
>                 Key: WFCORE-1010
>                 URL: https://issues.jboss.org/browse/WFCORE-1010
>             Project: WildFly Core
>          Issue Type: Patch
>          Components: Scripts
>            Reporter: Philippe Marschall
>            Assignee: Tomaz Cerar
>
> The {{standalone.sh}} file hard codes the {{org.jboss.boot.log.file}} property to {{server.log}}. This is inconvenient because it overrides the dynamic configuration in {{logging.properties}} which is set to ${org.jboss.boot.log.file:boot.log}. Maybe the value in logging.properties should instead default to {{server.log}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 15:04:00 2015
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Thu, 24 Sep 2015 15:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1012) Remove Tomcat modeler log
	configuration
In-Reply-To: <JIRA.12586063.1443121402000@Atlassian.JIRA>
References: <JIRA.12586063.1443121402000@Atlassian.JIRA>
	<JIRA.12586063.1443121402022@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586063.1443121402000.12982.1443121440131@Atlassian.JIRA>

Philippe Marschall created WFCORE-1012:
------------------------------------------

             Summary: Remove Tomcat modeler log configuration
                 Key: WFCORE-1012
                 URL: https://issues.jboss.org/browse/WFCORE-1012
             Project: WildFly Core
          Issue Type: Patch
          Components: Logging
            Reporter: Philippe Marschall
            Assignee: James Perkins


The org.apache.tomcat.util.modeler logger is still configured in several places. This seems to be a left over from the days when WildFly used Tomcat as a servlet implementation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 15:42:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 15:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5405) Remove unused security
 configuration properties from iiop-openjdk subsystem
In-Reply-To: <JIRA.12586068.1443123689000@Atlassian.JIRA>
References: <JIRA.12586068.1443123689000@Atlassian.JIRA>
	<JIRA.12586068.1443123689394@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586068.1443123689000.13076.1443123720054@Atlassian.JIRA>

Tomasz Adamski created WFLY-5405:
------------------------------------

             Summary: Remove unused security configuration properties from iiop-openjdk subsystem
                 Key: WFLY-5405
                 URL: https://issues.jboss.org/browse/WFLY-5405
             Project: WildFly
          Issue Type: Task
          Components: IIOP
    Affects Versions: 10.0.0.CR1
            Reporter: Tomasz Adamski
            Assignee: Tomasz Adamski


add-component-via-interceptor, client-supports, client-requires, server-supports, server-requires, use-domain-socket-factory, use-domain-server-socket-factory properties are JacORB specific and should be removed from subsystem configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 16:02:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 24 Sep 2015 16:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.13113.1443124920445@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112331#comment-13112331 ] 

Kabir Khan commented on WFLY-5290:
----------------------------------

I was going to add a test to check the theory, but it seems that AliasResourceTestCase.testAliasedResourceAndAttributeReadWriteFromAliased() already does an add for /aliased=model (in addCore()), which then gets translated to /core=model, and the add succeeds.

It has been a while since I last looked, but the problem to me appears to be in SimpleAliasEntry. I also see this infinite loop using standalone-ha.xml when doing /subsystem=jgroups/stack=tcp/transport=TRANSPORT:read-resource. The address returned by AliasStepHandler's call to SimpleAliasEntry.convertToTargetAddress() is the same as what is passed in. AliasStepHandler then adds a step for the 'real address'. However, since that 'real address' is still the original alias address, that step then resolves to AliasStepHandler again, and on and on it goes.

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 16:17:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 24 Sep 2015 16:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.13144.1443125820311@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112335#comment-13112335 ] 

Kabir Khan commented on WFLY-5290:
----------------------------------

https://github.com/wildfly/wildfly/blob/master/clustering/common/src/main/java/org/jboss/as/clustering/controller/SimpleAliasEntry.java#L51 probably explains it. The target address is a wildcard address transport=TRANSPORT, and it takes the 'transport' key from the target address, and adds the 'TRANSPORT' value from the operation/alias address. You probably want a different path conversion for this occurrence. 

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 16:23:00 2015
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Thu, 24 Sep 2015 16:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5405) Remove unused security
 configuration properties from iiop-openjdk subsystem
In-Reply-To: <JIRA.12586068.1443123689000@Atlassian.JIRA>
References: <JIRA.12586068.1443123689000@Atlassian.JIRA>
	<JIRA.12586068.1443123689000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586068.1443123689000.13169.1443126180051@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski updated WFLY-5405:
---------------------------------
    Description: add-component-via-interceptor, client-supports, server-supports, server-requires, use-domain-socket-factory, use-domain-server-socket-factory properties are JacORB specific and should be removed from subsystem configuration.  (was: add-component-via-interceptor, client-supports, client-requires, server-supports, server-requires, use-domain-socket-factory, use-domain-server-socket-factory properties are JacORB specific and should be removed from subsystem configuration.)


> Remove unused security configuration properties from iiop-openjdk subsystem
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5405
>                 URL: https://issues.jboss.org/browse/WFLY-5405
>             Project: WildFly
>          Issue Type: Task
>          Components: IIOP
>    Affects Versions: 10.0.0.CR1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>
> add-component-via-interceptor, client-supports, server-supports, server-requires, use-domain-socket-factory, use-domain-server-socket-factory properties are JacORB specific and should be removed from subsystem configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 17:09:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Sep 2015 17:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-751) Different threads accessing
 LeftTuple fields that reference LeftTupleSet
In-Reply-To: <JIRA.12567019.1427387255000@Atlassian.JIRA>
References: <JIRA.12567019.1427387255000@Atlassian.JIRA>
	<JIRA.12567019.1427387255000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567019.1427387255000.13220.1443128940415@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112344#comment-13112344 ] 

RH Bugzilla Integration commented on DROOLS-751:
------------------------------------------------

Alessandro Lazarotti <alazarot at redhat.com> changed the Status of [bug 1218291|https://bugzilla.redhat.com/show_bug.cgi?id=1218291] from VERIFIED to ASSIGNED

> Different threads accessing LeftTuple fields that reference LeftTupleSet
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-751
>                 URL: https://issues.jboss.org/browse/DROOLS-751
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.3.0.Beta1
>
>
> In class LeftTupleSetsImpl there are missing nullchecks in some methods that contains handling LeftTuple instances. I.e. in method removeInsert there is LeftTuple variable previous that is not nullchecked.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 17:10:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Sep 2015 17:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-921) Drools fires no rules with
 this Drools/CEP test
In-Reply-To: <JIRA.12585301.1442523320000@Atlassian.JIRA>
References: <JIRA.12585301.1442523320000@Atlassian.JIRA>
	<JIRA.12585301.1442523320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585301.1442523320000.13225.1443129000299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-921:
-------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1218291
        Bugzilla Update: Perform


> Drools fires no rules with this Drools/CEP test
> -----------------------------------------------
>
>                 Key: DROOLS-921
>                 URL: https://issues.jboss.org/browse/DROOLS-921
>             Project: Drools
>          Issue Type: Bug
>            Reporter: David Weir
>            Assignee: Mario Fusco
>         Attachments: DroolsLoopingTest.java, MyMessage.java
>
>
> I'm debugging a looping test and when I run the attached, it fires no rules



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 17:53:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 17:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.13251.1443131580257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene reassigned WFCORE-715:
-----------------------------------

    Assignee: Jason Greene  (was: Tomaz Cerar)


> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Jason Greene
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 18:07:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 18:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.13280.1443132420410@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFCORE-715:
--------------------------------
    Priority: Blocker  (was: Major)


> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 2.0.0.CR6
>
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 18:07:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 18:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.13286.1443132420628@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFCORE-715:
--------------------------------
    Fix Version/s: 2.0.0.CR6


> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 2.0.0.CR6
>
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 18:08:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-715) Xalan Linkage error :
 TransformerConfigurationException for domain setup
In-Reply-To: <JIRA.12572898.1432714713000@Atlassian.JIRA>
References: <JIRA.12572898.1432714713000@Atlassian.JIRA>
	<JIRA.12572898.1432714713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572898.1432714713000.13292.1443132480193@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112348#comment-13112348 ] 

Jason Greene commented on WFCORE-715:
-------------------------------------

We'll get this fixed in WF10, and ill look into a patch release for 9

> Xalan Linkage error : TransformerConfigurationException for domain setup
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-715
>                 URL: https://issues.jboss.org/browse/WFCORE-715
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.1.Final
>         Environment: Wildfly 8.2-Final Domain configuration
> Wildfly 9.0.1-Final Domain configuration
> JDK 1.8.0_45
> Windows only
>            Reporter: Renan Galang
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 2.0.0.CR6
>
>         Attachments: Transform.war, Transform.war
>
>
> Running into the same error as WFCORE-519, but on domain setup. Issue persists on 8.2-FINAL
> 	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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: com.lawson.util.eli.xslt.LawXsltException: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:148)
> 	at com.lawson.util.eli.xslt.LawTransform.transform(LawTransform.java:57)
> 	at com.lawson.servlet.Transform.doGet(Transform.java:218)
> 	... 42 more
> Caused by: javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:390)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:404)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:439)
> 	at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:792)
> 	at __redirected.__TransformerFactory.newTransformer(__TransformerFactory.java:132)
> 	at com.lawson.util.eli.xslt.LawTransform.doTransform(LawTransform.java:142)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 18:52:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Thu, 24 Sep 2015 18:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.13328.1443135120146@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112354#comment-13112354 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

Paul,

I'm just asking for a clear example of using TCPPING with alternate option for "timeout" as join_timeoutclearly does not work for TCPPING.  I don't understand how you can have a message of deprecated for this protocol with the suggestion of using "join_timeout" when that doesn't work.  If this doesn't work for TCPPING that why display this message?  I simply want to use TCPPING and what I pasted in here is what you find I many examples of using TCPPING.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 19:27:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-756) Core management server
 shutting down a thread pool early, resulting in RejectedExecutionException
In-Reply-To: <JIRA.12574648.1434021775000@Atlassian.JIRA>
References: <JIRA.12574648.1434021775000@Atlassian.JIRA>
	<JIRA.12574648.1434021775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574648.1434021775000.13402.1443137220392@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-756.
-------------------------------------
    Resolution: Done


> Core management server shutting down a thread pool early, resulting in RejectedExecutionException
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-756
>                 URL: https://issues.jboss.org/browse/WFCORE-756
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 2.0.0.CR5
>
>         Attachments: server.log, server.log
>
>
> In one of our tests, we've seen this exception during server shutdown:
> {code}
> 2015-06-05 10:34:44,387 ERROR [org.xnio.listener] (XNIO-1 I/O-2) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1 at 5e7925db rejected from org.xnio.XnioWorker$TaskPool at 3d00aa37[Shutting down, pool size = 7, active threads = 0, queued tasks = 0, completed tasks = 52]
> 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> 	at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> 	at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
> 	...
> {code}
> This is a very basic test that only starts the server and then shuts it down using {{:shutdown}}.
> After looking into this for a while, I believe that this is caused by the core management server ({{UndertowHttpManagementService}}) shutting down an XNIO worker (= thread pool) while the {{:shutdown}} management operation is still running (or, in fact, finishing, trying to close the network connection).
> I have a Byteman-based reproducer that inserts artifical pauses to certain well-defined places. I'm not sure if this has some connection to the graceful shutdown system, but I believe that even if it does, something like this shouldn't happen.
> Steps to reproduce:
> # {{./bin/standalone.sh -c standalone-full-ha.xml}} and wait until it starts completely
> # {{jps -v | grep "&#92;-D&#92;\[Standalone&#92;\]"}} to figure out the PID of the newly started server
> # {{bminstall.sh -b -Dorg.jboss.byteman.transform.all $PID}}
> # {{bmsubmit.sh reproducer.btm}}, where {{reproducer.btm}} is a Byteman script reproduced below
> # {{./bin/jboss-cli.sh -c}}
> # {{:read-resource}} repeat few times
> # {{:shutdown(timeout=1)}} (or plain {{:shutdown}})
> The Byteman script:
> {code}
> RULE XnioWorker.TaskPool/ThreadPoolExecutor shutdown
> CLASS java.util.concurrent.ThreadPoolExecutor
> METHOD shutdown()
> AFTER INVOKE advanceRunState
> IF TRUE
> DO Thread.sleep(10000)
> ENDRULE
> RULE Remoting onClose handler
> CLASS org.jboss.remoting3.remote.RemoteReadListener$1
> METHOD handleEvent(java.nio.channels.Channel)
> AT ENTRY
> IF TRUE
> DO Thread.sleep(5000)
> ENDRULE
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1002)
 TransactionalProtocolOperationHandler.AbortOperationHandler must initialize
 the ExecuteRequestContext before responding
In-Reply-To: <JIRA.12585720.1442956922000@Atlassian.JIRA>
References: <JIRA.12585720.1442956922000@Atlassian.JIRA>
	<JIRA.12585720.1442956922000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585720.1442956922000.13404.1443137280598@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1002:
-------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> TransactionalProtocolOperationHandler.AbortOperationHandler must initialize the ExecuteRequestContext before responding
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1002
>                 URL: https://issues.jboss.org/browse/WFCORE-1002
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR3
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> If in a race a COMPLETE_TX_REQUEST cancelling an op is processed by a server/slave HC before the original EXECUTE_TX_REQUEST is processed, when the EXECUTE_TX_REQUEST comes in the AbortOperationHandler attempts to respond with a "outcome"=>"cancelled" response. This will fail because the ExecutionRequestContext will not be initialized.
> In this situation the AbortOperationHandler should initialize the ERC.
> With assertions enabled, this appears in the log:
> {code}
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) Exception in thread "Remoting "slave:main-three:MANAGEMENT" task-6" java.lang.AssertionError
> 20:58:47,947 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.failed(TransactionalProtocolOperationHandler.java:458)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$AbortOperationHandler.handleRequest(TransactionalProtocolOperationHandler.java:275)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:252)
> 20:58:47,948 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:123)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)
> 20:58:47,949 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:705)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 20:58:47,950 ERROR [stderr] (Remoting "slave:main-three:MANAGEMENT" task-6) 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Without assertions, a few lines later a call to sendResponse will result in an NPE.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1001) Starting embedded server
 overwrites standalone/config/logging.properties with a mostly blank config
In-Reply-To: <JIRA.12585689.1442943974000@Atlassian.JIRA>
References: <JIRA.12585689.1442943974000@Atlassian.JIRA>
	<JIRA.12585689.1442943974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585689.1442943974000.13407.1443137280661@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1001:
-------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> Starting embedded server overwrites standalone/config/logging.properties with a mostly blank config
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1001
>                 URL: https://issues.jboss.org/browse/WFCORE-1001
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR6
>
>
> Note the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties
>  $ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> Check the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties, the file is empty.
> Starting standalone will restore the default contents.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 19:28:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-742) Unify linux and PowerShell
 scripts for jboss-cli in printing environment information
In-Reply-To: <JIRA.12574035.1433506962000@Atlassian.JIRA>
References: <JIRA.12574035.1433506962000@Atlassian.JIRA>
	<JIRA.12574035.1433506962000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574035.1433506962000.13429.1443137281074@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-742:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> Unify linux and PowerShell scripts for jboss-cli in printing environment information
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-742
>                 URL: https://issues.jboss.org/browse/WFCORE-742
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR6
>
>
> Powershell script jboss-cli.ps1 prints environment information. 
> *Steps to Reproduce:*
> # .\jboss-cli.ps1
> *Actual results:*
> {noformat}
> =========================================================================
>   WildFly Bootstrap Environment
>   JBOSS_HOME: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0
>   JBOSS_BASE_DIR: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0\standalone
>   JAVA: java
>   JAVA_OPTS: -Xms64M -Xmx512M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.ne
> t.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman
>   JBOSS_MODULEPATH: C:\Users\Administrator\playground\7.0.0.DR3\jboss-eap-7.0\modules
> =========================================================================
> 10:22:33,569 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 10:22:33,959 INFO  [org.jboss.as.cli.CommandContext] (main) You are disconnected at the moment. Type 'connect' to connec
> t to the server or 'help' for the list of supported commands.
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands
> .
> [disconnected /]
> {noformat}
> *Expected results:*
> {noformat}
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] 
> {noformat}
> \\
> \\
> ".\jboss-cli.ps1 --help" show too much logging information:
> *Steps to Reproduce:*
> # .\jboss-cli.ps1 --help
> *Actual results:*
> {noformat}
> ...
> 10:29:18,212 INFO  [org.jboss.as.cli.CommandContext] (main) Usage:
> Usage:
> 10:29:18,215 INFO  [org.jboss.as.cli.CommandContext] (main)
> 10:29:18,216 INFO  [org.jboss.as.cli.CommandContext] (main)   jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
>   jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> ...
> {noformat}
> *Expected results:*
> {noformat}
> Usage:
>   jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.13411.1443137280729@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-994:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR6
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-989) Premature registration of
 reconnecting server
In-Reply-To: <JIRA.12585427.1442632267000@Atlassian.JIRA>
References: <JIRA.12585427.1442632267000@Atlassian.JIRA>
	<JIRA.12585427.1442632267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585427.1442632267000.13413.1443137280771@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-989:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> Premature registration of reconnecting server
> ---------------------------------------------
>
>                 Key: WFCORE-989
>                 URL: https://issues.jboss.org/browse/WFCORE-989
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> ServerInventoryImpl.reconnectServer is registering the ProxyController for the reconnecting server with the DomainModelControllerService. The problem is that ProxyController is not yet in a state where it can forward requests to the server. That won't happen until the server calls back with a DomainServerProtocol.SERVER_RECONNECT_REQUEST and the ServerToHostProtocolHandler.ServerReconnectRequestHandler handles it. The effect is if a request for the server comes in during this window, it will fail. If that request is part of a domain operation rollout (because during the window the HC regarded the server as 'live' and instructed the DC to send rollout ops to it), then the domain rollout will be affected. This happened in the testsuite failure I just saw. Most significant logging is as follows:
> {code}
> 2015-09-18 17:59:32,229 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR2-SNAPSHOT "Kenny" (Host Controller) started in 93ms - Started 48 of 51 services (15 services are lazy, passive or on-demand)
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-16) Initialized for 1849055188
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-14) WFLYHC0021: Server [Server:main-three] connected using connection [Channel ID 08aa200b (inbound) of Remoting connection 27e3d90d to /127.0.0.1:49272]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.host.controller] (Remoting "slave:MANAGEMENT" task-15) WFLYHC0021: Server [Server:other-two] connected using connection [Channel ID 02bd2646 (inbound) of Remoting connection 64a8b7f2 to /127.0.0.1:49273]
> 2015-09-18 17:59:32,247 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) Initialized for 1849055188
> 2015-09-18 17:59:32,252 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 34) sending prepared response for 1849055188  --- interrupted: false
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Remoting "slave:MANAGEMENT" task-1) Initialized for 481103151
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) Initialized for 1933145457
> 2015-09-18 17:59:32,254 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) Initialized for 481103151
> 2015-09-18 17:59:32,255 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 36) sending pre-prepare failed response for 1933145457  --- interrupted: false
> 2015-09-18 17:59:32,256 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 37) sending pre-prepare failed response for 481103151  --- interrupted: false
> {code}
> The HC completes boot. Then servers main-three and other-two register. The HC sends a prepared response to a request. This is the host rollout request to the slave from the DC with the response being the ops to invoke on the servers. The HC reports sending a "pre-prepare failed response" to two requests. These are the requests the DC has asked it to proxy to the servers.
> The result of all this for the client is the following failure of a management op:
> {code}
> Failed operation:
> {
>     "operation" => "add",
>     "address" => [("extension" => "org.jboss.as.test.hc.extension")]
> }
> Response:
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"slave" => {"main-three" => "WFLYHC0153: Channel closed"}}},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => "WFLYHC0153: Channel closed"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {
>             "master" => {"main-one" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => [("HC" => "1.1.1")],
>                 "rolled-back" => true
>             }}},
>             "slave" => {"main-three" => {"response" => {
>                 "outcome" => "failed",
>                 "result" => undefined,
>                 "failure-description" => "WFLYHC0153: Channel closed",
>                 "rolled-back" => true
>             }}}
>         }},
>         "other-server-group" => {"host" => {"slave" => {"other-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYHC0153: Channel closed",
>             "rolled-back" => true
>         }}}}}
>     }
> }
> {code}
> The "WFLYHC0153: Channel closed" failure is what is produced when an attempt is made to invoke on a disconnected proxy controller.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-745) Standalone powershell script
 does't support --debug and -secmgr option
In-Reply-To: <JIRA.12574041.1433507267000@Atlassian.JIRA>
References: <JIRA.12574041.1433507267000@Atlassian.JIRA>
	<JIRA.12574041.1433507267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574041.1433507267000.13421.1443137280914@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-745:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> Standalone powershell script does't support --debug and -secmgr option
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-745
>                 URL: https://issues.jboss.org/browse/WFCORE-745
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR6
>
>
> Standalone powershell script does't support --debug option. Also -secmgr option and SECMGR=true environment variable settings is missing in posershell script. 
> *Steps to Reproduce:*
> # .\standalone.ps1 --debug
> *Actual results:*
> Debug mode is not active
> *Expected results:*
> {noformat}
> ...
> Listening for transport dt_socket at address: 8787
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-988) Host controller fails to
 roll out management operations if assertions are enabled
In-Reply-To: <JIRA.12585303.1442524923000@Atlassian.JIRA>
References: <JIRA.12585303.1442524923000@Atlassian.JIRA>
	<JIRA.12585303.1442524923000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585303.1442524923000.13417.1443137280841@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-988:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> Host controller fails to roll out management operations if assertions are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-988
>                 URL: https://issues.jboss.org/browse/WFCORE-988
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> Enabling assertions, {{-ea}}, for the host controller then trying to execute an operation that needs to be rolled out to servers fails. The issue seems to be in the [{{OperationContextImpl}}|https://github.com/wildfly/wildfly-core/blob/2.0.0.CR1/controller/src/main/java/org/jboss/as/controller/OperationContextImpl.java#L826].
> Replacing the assertion with an exception I see the stack trace below.
> {code:title=Stack Trace}
> [Host Controller] 14:08:33,124 DEBUG [org.jboss.as.host.controller] (Host Controller Service Threads - 8) failed to process task {
> [Host Controller]     "address" => [
> [Host Controller]         ("host" => "master"),
> [Host Controller]         ("server" => "server-one"),
> [Host Controller]         ("subsystem" => "logging")
> [Host Controller]     ],
> [Host Controller]     "operation" => "write-attribute",
> [Host Controller]     "name" => "use-deployment-logging-config",
> [Host Controller]     "value" => true,
> [Host Controller]     "operation-headers" => {
> [Host Controller]         "access-mechanism" => "NATIVE",
> [Host Controller]         "domain-uuid" => "1763a478-a1ad-42b5-a206-03db6e8bbc69",
> [Host Controller]         "execute-for-coordinator" => true
> [Host Controller]     }
> [Host Controller] }: java.lang.RuntimeException: Thread.currentThread=Thread[Host Controller Service Threads - 8,5,Host Controller Service Threads], controllingThread=null, initiatingThreadThread[management-handler-thread - 2,5,management-handler-thread]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:832)
> [Host Controller] 	at org.jboss.as.controller.transform.ResourceTransformationContextImpl.create(ResourceTransformationContextImpl.java:64)
> [Host Controller] 	at org.jboss.as.controller.transform.TransformersImpl.transformOperation(TransformersImpl.java:88)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$Factory$1.transformOperation(TransformingProxyController.java:102)
> [Host Controller] 	at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.transformOperation(TransformingProxyController.java:153)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.MultiphaseOverallContext.transformServerOperation(MultiphaseOverallContext.java:176)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.DomainRolloutStepHandler$2.execute(DomainRolloutStepHandler.java:315)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ServerTaskExecutor.executeTask(ServerTaskExecutor.java:83)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.ConcurrentServerGroupUpdateTask.execute(ConcurrentServerGroupUpdateTask.java:53)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:63)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask$1.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:360)
> [Host Controller] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Host Controller] 	at org.jboss.as.domain.controller.plan.AbstractServerGroupRolloutTask.run(AbstractServerGroupRolloutTask.java:59)
> [Host Controller] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [Host Controller] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 19:28:01 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-737) PowerShell script
	"vault.ps1" is missing
In-Reply-To: <JIRA.12574019.1433504541000@Atlassian.JIRA>
References: <JIRA.12574019.1433504541000@Atlassian.JIRA>
	<JIRA.12574019.1433504541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574019.1433504541000.13433.1443137281181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-737:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> PowerShell script "vault.ps1" is missing
> ----------------------------------------
>
>                 Key: WFCORE-737
>                 URL: https://issues.jboss.org/browse/WFCORE-737
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR6
>
>
> PowerShell scripts "vault.ps1" should be in JBOSS_HOME/bin



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 19:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 24 Sep 2015 19:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-744) Unify add-user script
 functionality in windows (powershell, bat) and linux
In-Reply-To: <JIRA.12574037.1433506978000@Atlassian.JIRA>
References: <JIRA.12574037.1433506978000@Atlassian.JIRA>
	<JIRA.12574037.1433506978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574037.1433506978000.13425.1443137280997@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-744:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR5)


> Unify add-user script functionality in windows (powershell, bat) and linux
> --------------------------------------------------------------------------
>
>                 Key: WFCORE-744
>                 URL: https://issues.jboss.org/browse/WFCORE-744
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.Alpha3
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>             Fix For: 2.0.0.CR6
>
>
> PowerShell scripts "add-user.ps1" is missing in EAP 7, "add-user.bat" and "add-user.sh" are in JBOSS_HOME/bin. If user is able to "add new user" by add-user.bat or add-user.sh, user should be also able to "add new user" with add-user.ps1



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Sep 24 20:05:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Sep 2015 20:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.13438.1443139500168@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112366#comment-13112366 ] 

Paul Ferraro commented on WFLY-5358:
------------------------------------

I don't understand the confusion.
"join_timeout clearly does not work for TCPPING."
As both the log message and my previous comment indicate, the replacement property, i.e. join_timeout, is a property of the pbcast.GMS protocol, not TCPPING.  GMS is not a discovery protocol - it is the group management protocol.  Both should exist in your stack.  All you need to do is move your timeout from your discovery protocol into the GMS protocol.

"I don't understand how you can have a message of deprecated for this protocol with the suggestion of using "join_timeout" when that doesn't work."
Of course it works.  I can't tell what your new configuration looks like. Please paste it if you're having problems.  Or better yet, post a comment to the forums, so others with similar issues can more easily find the solution.

"If this doesn't work for TCPPING that why display this message?"
See my first comment.

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 21:36:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 24 Sep 2015 21:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5406) Update to add a testcase for
 the journal store setting in the transaction subsystem
In-Reply-To: <JIRA.12586077.1443144931000@Atlassian.JIRA>
References: <JIRA.12586077.1443144931000@Atlassian.JIRA>
	<JIRA.12586077.1443144931633@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586077.1443144931000.13484.1443144960134@Atlassian.JIRA>

Amos Feng created WFLY-5406:
-------------------------------

             Summary: Update to add a testcase for the journal store setting in the transaction subsystem
                 Key: WFLY-5406
                 URL: https://issues.jboss.org/browse/WFLY-5406
             Project: WildFly
          Issue Type: Enhancement
          Components: Test Suite, Transactions
            Reporter: Amos Feng
            Assignee: Amos Feng






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 21:40:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Thu, 24 Sep 2015 21:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5406) Update to add a testcase for
 the journal store setting in the transaction subsystem
In-Reply-To: <JIRA.12586077.1443144931000@Atlassian.JIRA>
References: <JIRA.12586077.1443144931000@Atlassian.JIRA>
	<JIRA.12586077.1443144931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586077.1443144931000.13487.1443145200133@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amos Feng updated WFLY-5406:
----------------------------
    Priority: Minor  (was: Major)


> Update to add a testcase for the journal store setting in the transaction subsystem
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-5406
>                 URL: https://issues.jboss.org/browse/WFLY-5406
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite, Transactions
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 22:16:01 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 22:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5404) WF 10.0.0.CR2 with
 standalone.xml from WF 9 crashes on war deploy
In-Reply-To: <JIRA.12586005.1443108379000@Atlassian.JIRA>
References: <JIRA.12586005.1443108379000@Atlassian.JIRA>
	<JIRA.12586005.1443108379000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586005.1443108379000.13495.1443147361096@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5404:
-------------------------------
    Fix Version/s: 10.0.0.CR2


> WF 10.0.0.CR2 with standalone.xml from WF 9 crashes on war deploy
> -----------------------------------------------------------------
>
>                 Key: WFLY-5404
>                 URL: https://issues.jboss.org/browse/WFLY-5404
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 10.0.0.CR1
>            Reporter: Marko Strukelj
>            Assignee: James Perkins
>             Fix For: 10.0.0.CR2
>
>
> As I understand it Wildfly 10 wants to maintain configuration compatibility with Wildfly 9.
> It looks lake some of the compatibility was broken with CR1 (worked with Betas). 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 22:18:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 22:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5360) [Migration operation] [Web to
 Undertow] Migrating https connector in domain fails
In-Reply-To: <JIRA.12585329.1442564248000@Atlassian.JIRA>
References: <JIRA.12585329.1442564248000@Atlassian.JIRA>
	<JIRA.12585329.1442564248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585329.1442564248000.13499.1443147480193@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5360:
-------------------------------
    Fix Version/s: 10.0.0.CR2


> [Migration operation] [Web to Undertow] Migrating https connector in domain fails
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5360
>                 URL: https://issues.jboss.org/browse/WFLY-5360
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR2
>
>
> When trying to migrate https connector in domain, it fails during creation of security realm, as the operation assumes that security realms are set in domain also under {{/core-service=management/}} but they are set specifically for host => in case of host master it is {{/host=master/core-service=management/}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 22:18:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 22:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5349) Upgrade RESTEasy to
	3.0.13.Final
In-Reply-To: <JIRA.12585042.1442381036000@Atlassian.JIRA>
References: <JIRA.12585042.1442381036000@Atlassian.JIRA>
	<JIRA.12585042.1442381036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585042.1442381036000.13502.1443147480249@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5349:
-------------------------------
    Fix Version/s: 10.0.0.CR2


> Upgrade RESTEasy to 3.0.13.Final
> --------------------------------
>
>                 Key: WFLY-5349
>                 URL: https://issues.jboss.org/browse/WFLY-5349
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: REST
>            Reporter: Weinan Li
>            Assignee: Weinan Li
>             Fix For: 10.0.0.CR2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 22:25:00 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Thu, 24 Sep 2015 22:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3990) queue-length of
 standalone.xml should be set to a value larger then 0 e.g. 1000
In-Reply-To: <JIRA.12555422.1413550334000@Atlassian.JIRA>
References: <JIRA.12555422.1413550334000@Atlassian.JIRA>
	<JIRA.12555422.1413550334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555422.1413550334000.13507.1443147900281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3990:
-------------------------------
    Issue Type: Feature Request  (was: Enhancement)


> queue-length of standalone.xml should be set to a value larger then 0 e.g. 1000
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3990
>                 URL: https://issues.jboss.org/browse/WFLY-3990
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, EJB
>    Affects Versions: 8.1.0.Final
>         Environment: Mac OS X 10.9.5 JDK 1.8
>            Reporter: Manuel Blechschmidt
>            Assignee: James Perkins
>              Labels: Concurrency, ManagedExecutorService, Parallel, execution
>
> When  running a lot of tasks in an ManagedExecutorService (in my case 492) a RejectedExecutionException might be thrown.
> The main reason for this is that the queue-length is not set in standalone.xml in wildfly. I will provide a pull request fpr that.
> {code}
> 2014-10-17 11:27:37,076 ERROR [org.jboss.as.ejb3.invocation] (default task-10) JBAS014134: EJB Invocation failed on component LogAnalyzer for method public java.util.List de.mobizcorp.log.demandware_analyzer.LogAnalyzer.analyze(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws java.io.IOException,java.lang.IllegalAccessException,java.lang.IllegalArgumentException,java.lang.reflect.InvocationTargetException,java.beans.IntrospectionException,java.net.URISyntaxException: javax.ejb.EJBException: java.util.concurrent.RejectedExecutionException: Task org.glassfish.enterprise.concurrent.internal.ManagedFutureTask at 1d16d4d3 rejected from org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor at 10a6dce9[Running, pool size = 25, active threads = 25, queued tasks = 0, completed tasks = 492]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
>     at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$$$view2.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at de.mobizcorp.log.demandware_analyzer.LogAnalyzer$Proxy$_$$_Weld$EnterpriseProxy$.analyze(Unknown Source) [classes:]
>     at de.mobizcorp.log.jsf.Index.analyze(Index.java:39) [classes:]
>     at de.mobizcorp.log.jsf.Index$Proxy$_$$_WeldClientProxy.analyze(Unknown Source) [classes:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0]
>     at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0]
>     at com.sun.el.parser.AstValue.invoke(AstValue.java:275) [javax.el-3.0.0.jar:]
>     at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0.0.jar:]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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]
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Sep 24 23:23:00 2015
From: issues at jboss.org (Carlton Zachary (JIRA))
Date: Thu, 24 Sep 2015 23:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5358) JGRP000014: Discovery.timeout
 has been deprecated: GMS.join_timeout should be used instead
In-Reply-To: <JIRA.12585312.1442537197000@Atlassian.JIRA>
References: <JIRA.12585312.1442537197000@Atlassian.JIRA>
	<JIRA.12585312.1442537197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585312.1442537197000.13518.1443151380321@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112373#comment-13112373 ] 

Carlton Zachary commented on WFLY-5358:
---------------------------------------

Sorry,

I get your point.

Thanks

> JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5358
>                 URL: https://issues.jboss.org/browse/WFLY-5358
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR1
>            Reporter: Carlton Zachary
>            Assignee: Paul Ferraro
>
> I am getting the following in the server.log when using the HA profile and with a Cluster application deployed.
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead
> WARN  [org.jgroups.stack.Configurator] (MSC service thread 1-2) JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored
> JGroups configuration:
>  <stacks default="tcp">
> <stack name="tcp">
>                         <transport type="TCP" socket-binding="jgroups-tcp"/>
>                         <protocol type="TCPPING">
>                             <property name="initial_hosts">
>                                 ${jboss.cluster.tcp.initial_hosts}
>                             </property>
>                             <property name="num_initial_members">
>                                 2
>                             </property>
>                             <property name="port_range">
>                                 0
>                             </property>
>                             <property name="timeout">
>                                 2000
>                             </property>
>                         </protocol>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:05 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5392) Repeated Failure of
 EarPackagedMultiRarDeploymentTestCase
In-Reply-To: <JIRA.12585772.1443012363000@Atlassian.JIRA>
References: <JIRA.12585772.1443012363000@Atlassian.JIRA>
	<JIRA.12585772.1443012363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585772.1443012363000.13534.1443157325795@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5392:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Repeated Failure of EarPackagedMultiRarDeploymentTestCase 
> ----------------------------------------------------------
>
>                 Key: WFLY-5392
>                 URL: https://issues.jboss.org/browse/WFLY-5392
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Final
>
>
> The test is regularly failing, it could make it a candidate to be ignored but it does seem to stem from a NPE within the subsystem so maybe a fix is required: -
> {noformat}
> 13:36:23,229 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: org.jboss.msc.service.StartException in service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: 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.NullPointerException
>     at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.start(IronJacamarActivationResourceService.java:196)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:05 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix
 org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
 failure
In-Reply-To: <JIRA.12584552.1441887103000@Atlassian.JIRA>
References: <JIRA.12584552.1441887103000@Atlassian.JIRA>
	<JIRA.12584552.1441887103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584552.1441887103000.13537.1443157325888@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5319:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5319
>                 URL: https://issues.jboss.org/browse/WFLY-5319
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.Final
>
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:06 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.13548.1443157326388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5290:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 01:02:06 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5252) Fix MDB20TestCase
In-Reply-To: <JIRA.12583412.1441101182000@Atlassian.JIRA>
References: <JIRA.12583412.1441101182000@Atlassian.JIRA>
	<JIRA.12583412.1441101182000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583412.1441101182000.13551.1443157326492@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5252:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Fix MDB20TestCase
> -----------------
>
>                 Key: WFLY-5252
>                 URL: https://issues.jboss.org/browse/WFLY-5252
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Jeff Mesnil
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> The MDB20TestCase is failing often on our test suite with the error:
> {noformat}
> java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueB]
>     at org.junit.Assert.fail(Assert.java:88)
>     at org.junit.Assert.assertTrue(Assert.java:41)
>     at org.junit.Assert.assertNotNull(Assert.java:621)
>     at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:118)
> {noformat}
> From the logs, only 1 of the MDB receives the message sent to the topic.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:06 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:06 -0400 (EDT)
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.13556.1443157326613@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-5100:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 01:02:06 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4966) Make sure Weld work fine
 outside the full feature pack
In-Reply-To: <JIRA.12578599.1437399937000@Atlassian.JIRA>
References: <JIRA.12578599.1437399937000@Atlassian.JIRA>
	<JIRA.12578599.1437399937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578599.1437399937000.13559.1443157326711@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4966:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Make sure Weld work fine outside the full feature pack
> ------------------------------------------------------
>
>                 Key: WFLY-4966
>                 URL: https://issues.jboss.org/browse/WFLY-4966
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>             Fix For: 10.0.0.Final
>
>
> Review subsystem's dependencies and make them optional if appropriate. 
> http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004202.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:06 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4934) Make use of the new
 capabilities API in mod_cluster extension
In-Reply-To: <JIRA.12578224.1437000134000@Atlassian.JIRA>
References: <JIRA.12578224.1437000134000@Atlassian.JIRA>
	<JIRA.12578224.1437000134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578224.1437000134000.13562.1443157326776@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4934:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Make use of the new capabilities API in mod_cluster extension
> -------------------------------------------------------------
>
>                 Key: WFLY-4934
>                 URL: https://issues.jboss.org/browse/WFLY-4934
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:06 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4641) Restore javadoc generation to
 testsuite/shared
In-Reply-To: <JIRA.12571892.1431911412000@Atlassian.JIRA>
References: <JIRA.12571892.1431911412000@Atlassian.JIRA>
	<JIRA.12571892.1431911412000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571892.1431911412000.13566.1443157326925@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4641:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Restore javadoc generation to testsuite/shared
> ----------------------------------------------
>
>                 Key: WFLY-4641
>                 URL: https://issues.jboss.org/browse/WFLY-4641
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> I'm disabling the javadoc plugin for testsuite/shared, as it's failing when I try and deploy a release. This task is to look into re-enabling it.
> Failure was:
> {code}
> [ERROR] java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot be cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> [ERROR] at com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
> [ERROR] at com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
> [ERROR] at com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
> [ERROR] at com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
> [ERROR] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
> [ERROR] at com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
> [ERROR] at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:497)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
> [ERROR] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:192)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
> [ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
> [ERROR] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
> [ERROR] at com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:497)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
> [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:219)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:205)
> [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:64)
> [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:54)
> [ERROR] javadoc: error - java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot be cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> [ERROR] 
> [ERROR] Command line was: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:07 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4608) Omit no-op transaction if
 lifecycle method is missing
In-Reply-To: <JIRA.12571010.1431004453000@Atlassian.JIRA>
References: <JIRA.12571010.1431004453000@Atlassian.JIRA>
	<JIRA.12571010.1431004453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571010.1431004453000.13572.1443157327121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4608:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Omit no-op transaction if lifecycle method is missing
> -----------------------------------------------------
>
>                 Key: WFLY-4608
>                 URL: https://issues.jboss.org/browse/WFLY-4608
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.CR1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 10.0.0.Final
>
>
> LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:07 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails
 on Ubuntu 15.04
In-Reply-To: <JIRA.12570141.1430251970000@Atlassian.JIRA>
References: <JIRA.12570141.1430251970000@Atlassian.JIRA>
	<JIRA.12570141.1430251970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570141.1430251970000.13577.1443157327282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4570:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> wildfly-init-debian.sh fails on Ubuntu 15.04
> --------------------------------------------
>
>                 Key: WFLY-4570
>                 URL: https://issues.jboss.org/browse/WFLY-4570
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Beta2, 9.0.0.CR1
>         Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine.  Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is:
> Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory.
> Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:07 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4416) Cannot obtain
 DOMImplementationRegistry instance
In-Reply-To: <JIRA.12565354.1425984357000@Atlassian.JIRA>
References: <JIRA.12565354.1425984357000@Atlassian.JIRA>
	<JIRA.12565354.1425984357000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565354.1425984357000.13583.1443157327500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4416:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Cannot obtain DOMImplementationRegistry instance
> ------------------------------------------------
>
>                 Key: WFLY-4416
>                 URL: https://issues.jboss.org/browse/WFLY-4416
>             Project: WildFly
>          Issue Type: Bug
>          Components: XML Frameworks
>    Affects Versions: 8.2.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Jason Greene
>             Fix For: 10.0.0.Final
>
>
> {code}
> testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase)  Time elapsed: 0.09 sec  <<< ERROR!
> java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> 	at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182)
> 	at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:07 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4404) View does not inherit
 'default' methods from interfaces( JDK8 )
In-Reply-To: <JIRA.12564873.1425545957000@Atlassian.JIRA>
References: <JIRA.12564873.1425545957000@Atlassian.JIRA>
	<JIRA.12564873.1425545957000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564873.1425545957000.13588.1443157327731@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4404:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> View does not inherit 'default' methods from interfaces( JDK8 )
> ---------------------------------------------------------------
>
>                 Key: WFLY-4404
>                 URL: https://issues.jboss.org/browse/WFLY-4404
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 10.0.0.Final
>
>
> View and View service do not inherit JDK8 'default' methods from interfaces.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:07 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4265) Add support for caching
	handler
In-Reply-To: <JIRA.12561188.1421681349000@Atlassian.JIRA>
References: <JIRA.12561188.1421681349000@Atlassian.JIRA>
	<JIRA.12561188.1421681349000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561188.1421681349000.13595.1443157327897@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4265:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Add support for caching handler
> -------------------------------
>
>                 Key: WFLY-4265
>                 URL: https://issues.jboss.org/browse/WFLY-4265
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Final
>
>
> Currently we cannot configure CacheHandler as it requires DirectCache as parameter in constructor.
> One option to fix this is to have few cache handler impls that would only have primitive parameters in constructor or  getters / setters that would configure direct cache.
> Or add proper type cache configuration to undertow subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:07 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4186) Improve Infinispan module
 compatibility with older releases
In-Reply-To: <JIRA.12559699.1418744634000@Atlassian.JIRA>
References: <JIRA.12559699.1418744634000@Atlassian.JIRA>
	<JIRA.12559699.1418744634000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559699.1418744634000.13599.1443157327980@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-4186:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Improve Infinispan module compatibility with older releases
> -----------------------------------------------------------
>
>                 Key: WFLY-4186
>                 URL: https://issues.jboss.org/browse/WFLY-4186
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Final
>
>
> Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module (which, itself, was introduced in Infinispan 6), which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
> I suggest we either:
> 1. Export org.infinispan.commons from the org.infinispan module
> 2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3921) Support direct JMX mbeans as
	dependecies
In-Reply-To: <JIRA.12553872.1412175689000@Atlassian.JIRA>
References: <JIRA.12553872.1412175689000@Atlassian.JIRA>
	<JIRA.12553872.1412175689000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553872.1412175689000.13603.1443157328275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3921:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Support direct JMX mbeans as dependecies
> ----------------------------------------
>
>                 Key: WFLY-3921
>                 URL: https://issues.jboss.org/browse/WFLY-3921
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMX
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: 10.0.0.Final
>
>
> We should be able to depend on existing mbeans from jboss-service.xml.
> (e.g. mbeans registered directly from JMX API)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3909) Upgrade PicketBox
In-Reply-To: <JIRA.12553527.1411944613000@Atlassian.JIRA>
References: <JIRA.12553527.1411944613000@Atlassian.JIRA>
	<JIRA.12553527.1411944613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553527.1411944613000.13608.1443157328623@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3909:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Upgrade PicketBox
> -----------------
>
>                 Key: WFLY-3909
>                 URL: https://issues.jboss.org/browse/WFLY-3909
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Peter Skopek
>             Fix For: 10.0.0.Final
>
>
> Upgrade PicketBox to a version which resolves SECURITY-861.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3860) Improve dependency handling
 in clustering/infinispan subsystem tests
In-Reply-To: <JIRA.12552335.1410879436000@Atlassian.JIRA>
References: <JIRA.12552335.1410879436000@Atlassian.JIRA>
	<JIRA.12552335.1410879436000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552335.1410879436000.13613.1443157328763@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3860:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Improve dependency handling in clustering/infinispan subsystem tests
> --------------------------------------------------------------------
>
>                 Key: WFLY-3860
>                 URL: https://issues.jboss.org/browse/WFLY-3860
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 10.0.0.Final
>
>
> The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started.
> This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions.
> Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail.
> I plan to:
> 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model.
> 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that:
> a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.)
> b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy.
> The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3853) Cache PersistenceProviders
 within the same deployment
In-Reply-To: <JIRA.12552031.1410554803000@Atlassian.JIRA>
References: <JIRA.12552031.1410554803000@Atlassian.JIRA>
	<JIRA.12552031.1410554803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552031.1410554803000.13617.1443157328852@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3853:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Cache PersistenceProviders within the same deployment
> -----------------------------------------------------
>
>                 Key: WFLY-3853
>                 URL: https://issues.jboss.org/browse/WFLY-3853
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.Final
>
>
> See wildfly-dev ml discussion [http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html] about calls to PersistenceProviderResolver.getPersistenceProviders() should return a cached list.  The cache should be per deployment.  
> We can probably reuse our PersistenceProviderResolverImpl.persistenceProviderPerClassLoader map, just need to be careful that addDeploymentSpecificPersistenceProvider() is called early before any calls to getPersistenceProviders().



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:08 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3827) Update Subsystem for
	PicketLink Console
In-Reply-To: <JIRA.12551355.1410181392000@Atlassian.JIRA>
References: <JIRA.12551355.1410181392000@Atlassian.JIRA>
	<JIRA.12551355.1410181392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551355.1410181392000.13620.1443157328923@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3827:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Update Subsystem for PicketLink Console
> ---------------------------------------
>
>                 Key: WFLY-3827
>                 URL: https://issues.jboss.org/browse/WFLY-3827
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3816) ClassNotFoundException
 com.ibm.crypto.provider.IBMJCE with IBM JDK
In-Reply-To: <JIRA.12551200.1409906653000@Atlassian.JIRA>
References: <JIRA.12551200.1409906653000@Atlassian.JIRA>
	<JIRA.12551200.1409906653000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551200.1409906653000.13625.1443157329046@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3816:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> ClassNotFoundException com.ibm.crypto.provider.IBMJCE with IBM JDK
> ------------------------------------------------------------------
>
>                 Key: WFLY-3816
>                 URL: https://issues.jboss.org/browse/WFLY-3816
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.1.0.Final
>         Environment: Linux / Aix ; IBM JDK 1.6
>            Reporter: Yannick Lorenzati
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> I use Jboss AS 7.2.0 with IBM JDK 1.6
> One of my applications try to load the security provider com.ibm.crypto.provider.IBMJCE but I got an ClassNotFoundException.
> I think it?s because in the ibm.jdk module.xml we need to add the package of the security provider like this
> <module xmlns="urn:jboss:module:1.1" name="ibm.jdk">
>     <resources>
>     </resources>
>     <dependencies>
>         <system export="true">
>             <paths>
>                 <path name="com/ibm"/>
>                 <path name="com/ibm/jvm"/>
>                 <path name="com/ibm/jvm/io"/>
>                 <path name="com/ibm/jvm/util"/>
>                 <path name="com/ibm/match"/>
>                 <path name="com/ibm/misc"/>
>                 <path name="com/ibm/net"/>
>                 <path name="com/ibm/nio"/>
>                 <path name="com/ibm/nio/ch"/>
>                 <path name="com/ibm/security/auth"/>
>                 <path name="com/ibm/security/bootstrap"/>
>                 <path name="com/ibm/security/auth/module"/>
>                 <path name="com/ibm/security/util"/>
>             </paths>
>         </system>
>     </dependencies>
> </module> 
> We need to add this 
>     	<path name="com/ibm/crypto"/>
>          <path name="com/ibm/crypto/provider"/>
> Can't do a pull request at work, but i hope this help



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3805)
 JGroupsBroadcastGroupConfiguration Serialization Problem
In-Reply-To: <JIRA.12550991.1409749047000@Atlassian.JIRA>
References: <JIRA.12550991.1409749047000@Atlassian.JIRA>
	<JIRA.12550991.1409749047000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550991.1409749047000.13630.1443157329183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3805:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> JGroupsBroadcastGroupConfiguration Serialization Problem
> --------------------------------------------------------
>
>                 Key: WFLY-3805
>                 URL: https://issues.jboss.org/browse/WFLY-3805
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.1.0.Final
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 10.0.0.Final
>
>
> When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3639) default-web-module doesn't
 work for non default host
In-Reply-To: <JIRA.12546798.1405638566000@Atlassian.JIRA>
References: <JIRA.12546798.1405638566000@Atlassian.JIRA>
	<JIRA.12546798.1405638566000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546798.1405638566000.13639.1443157329385@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3639:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> default-web-module doesn't work for non default host
> ----------------------------------------------------
>
>                 Key: WFLY-3639
>                 URL: https://issues.jboss.org/browse/WFLY-3639
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Final
>
>
> If you use config like this:
> {code:xml}
> <host name="default-host" default-web-module="myapp1.war" alias="webapp.domain1.com"/>
>     <host name="other-host" default-web-module="myapp2.war" alias="test.domain2.net"/>
> {code}
> and have apps myapp1.war & myapp2.war deployed myappwar2.war won't be bind to other-host.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3612) Implement missing
 transformers for new bean validation subsystem
In-Reply-To: <JIRA.12546142.1405043868000@Atlassian.JIRA>
References: <JIRA.12546142.1405043868000@Atlassian.JIRA>
	<JIRA.12546142.1405043868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546142.1405043868000.13643.1443157329459@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3612:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Implement missing transformers for new bean validation subsystem
> ----------------------------------------------------------------
>
>                 Key: WFLY-3612
>                 URL: https://issues.jboss.org/browse/WFLY-3612
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, EE
>            Reporter: Brian Stansberry
>            Assignee: Eduardo Martins
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>
> The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFLY-3563 is done.
> From my comment on the PR for the WFLY-3551 work:
> There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.
> If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But
> 1) it's a corner case
> 2) it may not matter anyway in terms of behavior of an app
> 3) the transformer logic we have doesn't allow us to do anything about it anyway.
> Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3608) Expose configuring allowed
	file extensions
In-Reply-To: <JIRA.12546105.1405016043000@Atlassian.JIRA>
References: <JIRA.12546105.1405016043000@Atlassian.JIRA>
	<JIRA.12546105.1405016043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546105.1405016043000.13653.1443157329659@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3608:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Expose configuring allowed file extensions
> ------------------------------------------
>
>                 Key: WFLY-3608
>                 URL: https://issues.jboss.org/browse/WFLY-3608
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>         Environment: CentOs 5.5 & Ubuntu 10.04/12.04, Wildfly 8.1.0 Final, java version 1.7.0_60
>            Reporter: Thomas Brenna
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Final
>
>
> It should be possible to modify allowed extensions without adding web.xml entry as we have it now.
> It should be an configuration option of servlet-container element. in undertow subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3583) Convert mod_cluster excluded
 context into an xs:list of host:context
In-Reply-To: <JIRA.12545575.1404411193000@Atlassian.JIRA>
References: <JIRA.12545575.1404411193000@Atlassian.JIRA>
	<JIRA.12545575.1404411193000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545575.1404411193000.13656.1443157329727@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3583:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Convert mod_cluster excluded context into an xs:list of host:context
> --------------------------------------------------------------------
>
>                 Key: WFLY-3583
>                 URL: https://issues.jboss.org/browse/WFLY-3583
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Final
>
>
> {noformat}
>     // TODO: Convert into an xs:list of host:context
>     static final SimpleAttributeDefinition EXCLUDED_CONTEXTS = SimpleAttributeDefinitionBuilder.create(CommonAttributes.EXCLUDED_CONTEXTS, ModelType.STRING, true)
>             .setAllowExpression(true)
>             .setDefaultValue(new ModelNode("ROOT,invoker,jbossws,juddi,console"))
>             .setRestartAllServices()
>             .build();
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
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.13659.1443157329784@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3582:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> 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
>             Fix For: 10.0.0.Final
>
>
> As per https://github.com/wildfly/wildfly/pull/6449



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3573) Adding incorrect JGroups
 protocol should provide better error description than CNFE
In-Reply-To: <JIRA.12545317.1404299531000@Atlassian.JIRA>
References: <JIRA.12545317.1404299531000@Atlassian.JIRA>
	<JIRA.12545317.1404299531000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545317.1404299531000.13664.1443157329877@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3573:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Adding incorrect JGroups protocol should provide better error description than CNFE
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-3573
>                 URL: https://issues.jboss.org/browse/WFLY-3573
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>              Labels: ux
>             Fix For: 10.0.0.Final
>
>
> As reported by the community user:
> {noformat}
> [standalone at localhost:9990 / #] list-batch
> #1 /subsystem=jgroups/stack=test:add()
> #2 /subsystem=jgroups/stack=test/transport=TRANSPORT:add(type="udp",socket-binding=jgroups-udp)
> #3 /subsystem=jgroups/stack=test:add-protocol(type=FD_SOCK,socket-binding=jgroups-udp-fd)
> [standalone at localhost:9990 / #] run-batch 
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0158: Operation handler failed: java.lang.ClassNotFoundException: org.jgroups.protocols.udp from [Module \"org.jboss.as.clustering.jgroups:main\" from local module loader @4d9f6ce5 (finder: local module finder @1da65633 (roots: /home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules,/home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]"}}
> [standalone at localhost:9990 / #] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:09 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3555) Find better place / fix
 @ignored tests in core suite
In-Reply-To: <JIRA.12545051.1403904664000@Atlassian.JIRA>
References: <JIRA.12545051.1403904664000@Atlassian.JIRA>
	<JIRA.12545051.1403904664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545051.1403904664000.13667.1443157329945@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3555:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Find better place / fix @ignored tests in core suite
> ----------------------------------------------------
>
>                 Key: WFLY-3555
>                 URL: https://issues.jboss.org/browse/WFLY-3555
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Final
>
>
> tests that need revisiting and cleanup / moving stuff around:
> org.wildfly.core.test.standalone.mgmt.api.ValidateOperationOperationTestCase
> org.jboss.as.test.integration.management.http.HttpPostMgmtOpsTestCase#testAddRemoveOperation



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still
 fails intermittently
In-Reply-To: <JIRA.12544517.1403276265000@Atlassian.JIRA>
References: <JIRA.12544517.1403276265000@Atlassian.JIRA>
	<JIRA.12544517.1403276265000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544517.1403276265000.13672.1443157330076@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3532:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


>  RemoteFailoverTestCase still fails intermittently
> --------------------------------------------------
>
>                 Key: WFLY-3532
>                 URL: https://issues.jboss.org/browse/WFLY-3532
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.Final
>
>
> Fail rate is at 1.5% atm.
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=3213279503671281753&tab=testDetails
> (making affected version alpha, but indeed its master)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:10 -0400 (EDT)
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.13682.1443157330529@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3434:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> 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
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Final
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2982) refactor two phase
 persistence unit services (PhaseOnePersistenceUnitServiceImpl +
 PersistenceUnitServiceImpl) into one service
In-Reply-To: <JIRA.12532872.1392925405000@Atlassian.JIRA>
References: <JIRA.12532872.1392925405000@Atlassian.JIRA>
	<JIRA.12532872.1392925405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532872.1392925405000.13684.1443157330577@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2982:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2982
>                 URL: https://issues.jboss.org/browse/WFLY-2982
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.Final
>
>
> Related feedback from https://github.com/wildfly/wildfly/pull/4722:
> {quote}
> This is asymetrical, so if this service , and phase one are stopped, and then phase 1 is started again, phase 2 will appear started. The side effects seem minor though
> {quote}
> {quote}
> We have a long term goal to somehow verify every service can be stopped and started with the expected effect. Right now many of our services are not restartable which makes potential new features like partial deployment standby hard to achieve. So Im just offering pointers whenever I see lifecycle symmetry issues.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3463)
 org.apache.cxf.wsdl11.WSDLManagerImpl needs read access to the jre
 wsdl.properties
In-Reply-To: <JIRA.12543100.1402074279000@Atlassian.JIRA>
References: <JIRA.12543100.1402074279000@Atlassian.JIRA>
	<JIRA.12543100.1402074279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543100.1402074279000.13677.1443157330371@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-3463:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> org.apache.cxf.wsdl11.WSDLManagerImpl needs read access to the jre wsdl.properties
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-3463
>                 URL: https://issues.jboss.org/browse/WFLY-3463
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security Manager
>    Affects Versions: 9.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Final
>
>
> During TCK testing (with security-manager enabled), I am seeing a java.security.AccessControlException: WFSM000001: Permission check failed for ("java.io.FilePermission" "/qa/tools/opt/x86_64/jdk1.7.0_60/jre/lib/wsdl.properties" "read")
> from org.apache.cxf.wsdl11.WSDLManagerImpl.
> Some related comments from irc:
> {quote}
> http://sourceforge.net/p/wsdl4j/patches/1/
> <asoldano> smarlow, I'm currently working around the problem (when running with security manager on) by setting "-Djavax.wsdl.factory.WSDLFactory=com.ibm.wsdl.factory.WSDLFactoryImpl" when starting the jvm
> {quote}
> Seems related to [https://issues.apache.org/jira/browse/TUSCANY-3925] which also has a patch.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2858) JPA doesn't parse for
 "urn:jboss:jpa" namespace in jboss-all.xml
In-Reply-To: <JIRA.12531038.1391444897000@Atlassian.JIRA>
References: <JIRA.12531038.1391444897000@Atlassian.JIRA>
	<JIRA.12531038.1391444897000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531038.1391444897000.13693.1443157330804@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2858:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> JPA doesn't parse for "urn:jboss:jpa" namespace in jboss-all.xml
> ----------------------------------------------------------------
>
>                 Key: WFLY-2858
>                 URL: https://issues.jboss.org/browse/WFLY-2858
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> Looks like the parser is only parsing for "http://www.jboss.com/xml/ns/javaee" and never for "urn:jboss:jpa". This makes the schema less useful.
> https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/docs/schema/jboss-jpa_1_0.xsd
> Example file:
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/epcpropagation/shallow/jboss-all.xml



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:10 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2876) Add mod_cluster support for
 all Undertow servers, not only the default-server
In-Reply-To: <JIRA.12531396.1391704235000@Atlassian.JIRA>
References: <JIRA.12531396.1391704235000@Atlassian.JIRA>
	<JIRA.12531396.1391704235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531396.1391704235000.13689.1443157330708@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2876:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Add mod_cluster support for all Undertow servers, not only the default-server
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2876
>                 URL: https://issues.jboss.org/browse/WFLY-2876
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Final
>
>
> Currently only the default host is registered with the proxy.
> This will require:
> * configuration change for listener<>host mapping
> * instance-id be configured per server, instead of per whole undertow subsystem (or just appended to the unique server name)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2845) On WildFly clean shutdown:
 failed marshalling rsp (UnsuccessfulResponse)
In-Reply-To: <JIRA.12530755.1391092956000@Atlassian.JIRA>
References: <JIRA.12530755.1391092956000@Atlassian.JIRA>
	<JIRA.12530755.1391092956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530755.1391092956000.13698.1443157331088@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2845:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2845
>                 URL: https://issues.jboss.org/browse/WFLY-2845
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: RHEL6 x86_64; Oracle JDK 7
>            Reporter: Michal Karm Babacek
>            Assignee: Paul Ferraro
>              Labels: clustering
>             Fix For: 10.0.0.Final
>
>
> I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}}  [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:
> {noformat}
> 08:59:33,341 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
> 08:59:33,368 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
> 08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,392 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms
> {noformat}
> In the log.  It's a non-deterministic problem and it does not emerge always.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2652) Add/remove load metric
 operations should not require service restart
In-Reply-To: <JIRA.12527929.1386945153000@Atlassian.JIRA>
References: <JIRA.12527929.1386945153000@Atlassian.JIRA>
	<JIRA.12527929.1386945153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527929.1386945153000.13702.1443157331214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2652:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Add/remove load metric operations should not require service restart
> --------------------------------------------------------------------
>
>                 Key: WFLY-2652
>                 URL: https://issues.jboss.org/browse/WFLY-2652
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2492) <valid-connection-checker>
 does not have module attribute
In-Reply-To: <JIRA.12524847.1384237418000@Atlassian.JIRA>
References: <JIRA.12524847.1384237418000@Atlassian.JIRA>
	<JIRA.12524847.1384237418000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524847.1384237418000.13710.1443157331447@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2492:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> <valid-connection-checker> does not have module attribute
> ---------------------------------------------------------
>
>                 Key: WFLY-2492
>                 URL: https://issues.jboss.org/browse/WFLY-2492
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: James Livingston
>            Assignee: Lin Gao
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>
> A datasource's <valid-connection-checker> element lets you specify the class name. It does not let you specify the module name, so you can only use IJ-provided ones.  It should let you specify a module name too, so you can use custom connection checkers.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2448) Print IOR to a user specified
	file
In-Reply-To: <JIRA.12518153.1383748388000@Atlassian.JIRA>
References: <JIRA.12518153.1383748388000@Atlassian.JIRA>
	<JIRA.12518153.1383748388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518153.1383748388000.13715.1443157331620@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2448:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Print IOR to a user specified file
> ----------------------------------
>
>                 Key: WFLY-2448
>                 URL: https://issues.jboss.org/browse/WFLY-2448
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows, Solaris, Linux
>            Reporter: Sumanth M S
>            Assignee: Stefan Guilhen
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>         Attachments: WFLY-2448.patch
>
>
> Jboss AS prints Corba IOR on console or log file. Many applications look for a file at a predefined location from where it can read the IOR; as it is difficult to read IOR programatically from a log file or console.
> An environment variable can be defined in standalone.conf to let the user specify the file location to which JBoss will print the IOR along with printing on the console.
> The solution has been tried and seems working. Please let us know if the solution can be submitted.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:11 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2426) Easily accessible static
 information describing the release
In-Reply-To: <JIRA.12509239.1383250273000@Atlassian.JIRA>
References: <JIRA.12509239.1383250273000@Atlassian.JIRA>
	<JIRA.12509239.1383250273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509239.1383250273000.13723.1443157331789@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2426:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Easily accessible static information describing the release
> -----------------------------------------------------------
>
>                 Key: WFLY-2426
>                 URL: https://issues.jboss.org/browse/WFLY-2426
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Ondrej Zizka
>              Labels: build, integration, jbds, layers, version
>             Fix For: 10.0.0.Final
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization for



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:12 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@Atlassian.JIRA>
References: <JIRA.12509159.1383210125000@Atlassian.JIRA>
	<JIRA.12509159.1383210125000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.13738.1443157332357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2422:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFLY-2422
>                 URL: https://issues.jboss.org/browse/WFLY-2422
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.Final
>
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350000@Atlassian.JIRA>
References: <JIRA.12508815.1382711350000@Atlassian.JIRA>
	<JIRA.12508815.1382711350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350000.13767.1443157333299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2387:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Scott Marlow
>             Fix For: 10.0.0.Final
>
>         Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	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) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2297) Log reasons for implicit
	dependencies
In-Reply-To: <JIRA.12502954.1381757546000@Atlassian.JIRA>
References: <JIRA.12502954.1381757546000@Atlassian.JIRA>
	<JIRA.12502954.1381757546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502954.1381757546000.13771.1443157333546@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2297:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Log reasons for implicit dependencies
> -------------------------------------
>
>                 Key: WFLY-2297
>                 URL: https://issues.jboss.org/browse/WFLY-2297
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> We should log a {{DEBUG}} or {{TRACE}} message whenever we add an implicit dependency to a module, documenting the reason for the addition (e.g. adding because it's a servlet deployment, or because a particular annotation was used, etc.)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2102) Improve deployment annotation
 parsing error message
In-Reply-To: <JIRA.12500878.1379471722000@Atlassian.JIRA>
References: <JIRA.12500878.1379471722000@Atlassian.JIRA>
	<JIRA.12500878.1379471722000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500878.1379471722000.13776.1443157333701@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2102:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


>  Improve deployment annotation parsing error message 
> -----------------------------------------------------
>
>                 Key: WFLY-2102
>                 URL: https://issues.jboss.org/browse/WFLY-2102
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: 10.0.0.Final
>
>
> Improve deployment annotation parsing error message 
> Code such as this below, will error with IllegalArgumentException: Empty name segment is not allowed for env.  The env is not enough information to identify what the issue is.
> @Singleton
> @Startup
> public class TestEJB {
>   @Resource(name="/queue/test")
>   private Queue queue;
> }
> Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed for env
> 	at org.jboss.msc.service.ServiceName.of(ServiceName.java:85) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> 	at org.jboss.msc.service.ServiceName.append(ServiceName.java:112) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> 	at org.jboss.as.naming.deployment.ContextNames.buildServiceName(ContextNames.java:183)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:195)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:186)
> 	at org.jboss.as.naming.deployment.ContextNames.bindInfoFor(ContextNames.java:141)
> 	at org.jboss.as.ee.component.OptionalLookupInjectionSource.getResourceValue(OptionalLookupInjectionSource.java:84)
> 	at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:1019)
> 	at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:998)
> 	at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:138)
> 	at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95)
> 	... 6 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:13 -0400 (EDT)
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.13782.1443157333831@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2100:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> 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
>             Fix For: 10.0.0.Final
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:13 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1882) JCA should be able to access
 the CDI-enabled ValidatorFactory
In-Reply-To: <JIRA.12498614.1376506818000@Atlassian.JIRA>
References: <JIRA.12498614.1376506818000@Atlassian.JIRA>
	<JIRA.12498614.1376506818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498614.1376506818000.13787.1443157333933@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1882:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> JCA should be able to access the CDI-enabled ValidatorFactory
> -------------------------------------------------------------
>
>                 Key: WFLY-1882
>                 URL: https://issues.jboss.org/browse/WFLY-1882
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Farah Juma
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Final
>
>
> The JCAValidatorFactory is currently a copy of an older version of the EE LazyValidatorFactory. The delegate of the EE LazyValidatorFactory was recently replaced with a CDI-enabled ValidatorFactory (see WFLY-529). JCA needs to be able to access the CDI-enabled ValidatorFactory as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1878) Make concurrency items in ee
 subsystem use KeepAliveTimeAttributeDefinition
In-Reply-To: <JIRA.12498581.1376490516000@Atlassian.JIRA>
References: <JIRA.12498581.1376490516000@Atlassian.JIRA>
	<JIRA.12498581.1376490516000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498581.1376490516000.13791.1443157334020@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1878:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Make concurrency items in ee subsystem use KeepAliveTimeAttributeDefinition
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1878
>                 URL: https://issues.jboss.org/browse/WFLY-1878
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, EE
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.0.Final
>
>
> Have the time-period attributes in ee use KeepAliveAD (or a renamed, slightly more generic version thereof.)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1877) Make
 KeepAliveTimeAttributeDefinition deal with both a simple long and a complex
 attribute
In-Reply-To: <JIRA.12498579.1376490426000@Atlassian.JIRA>
References: <JIRA.12498579.1376490426000@Atlassian.JIRA>
	<JIRA.12498579.1376490426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498579.1376490426000.13795.1443157334152@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1877:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Make KeepAliveTimeAttributeDefinition deal with both a simple long and a complex attribute
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1877
>                 URL: https://issues.jboss.org/browse/WFLY-1877
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.0.Final
>
>
> This attribute should support either a simple value or a complex one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1832) Wildfly High Availability
 Guide: Migration and Changes From Previous Versions write up
In-Reply-To: <JIRA.12497993.1375720397000@Atlassian.JIRA>
References: <JIRA.12497993.1375720397000@Atlassian.JIRA>
	<JIRA.12497993.1375720397000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497993.1375720397000.13799.1443157334235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1832:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Wildfly High Availability Guide: Migration and Changes From Previous Versions write up 
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-1832
>                 URL: https://issues.jboss.org/browse/WFLY-1832
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Final
>
>
> https://docs.jboss.org/author/display/WFLY8/Changes+From+Previous+Versions



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1831) Wildfly High Availability
 Guide: Clustering Monitor subsystem write up
In-Reply-To: <JIRA.12497992.1375720334000@Atlassian.JIRA>
References: <JIRA.12497992.1375720334000@Atlassian.JIRA>
	<JIRA.12497992.1375720334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497992.1375720334000.13803.1443157334349@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1831:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Wildfly High Availability Guide: Clustering Monitor subsystem write up
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1831
>                 URL: https://issues.jboss.org/browse/WFLY-1831
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.Final
>
>
> https://docs.jboss.org/author/display/WFLY8/Clustering+Monitor+Subsystem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1827) Wildfly High Availability
 Guide: Clustered Single Sign-on (SSO) write up
In-Reply-To: <JIRA.12497988.1375720092000@Atlassian.JIRA>
References: <JIRA.12497988.1375720092000@Atlassian.JIRA>
	<JIRA.12497988.1375720092000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497988.1375720092000.13810.1443157334478@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1827:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Wildfly High Availability Guide: Clustered Single Sign-on (SSO) write up
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1827
>                 URL: https://issues.jboss.org/browse/WFLY-1827
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Final
>
>
> https://docs.jboss.org/author/display/WFLY8/Clustered+SSO



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1829) Wildfly High Availability
 Guide: EJB Services/Subsystem write up
In-Reply-To: <JIRA.12497990.1375720208000@Atlassian.JIRA>
References: <JIRA.12497990.1375720208000@Atlassian.JIRA>
	<JIRA.12497990.1375720208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497990.1375720208000.13806.1443157334411@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1829:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Wildfly High Availability Guide: EJB Services/Subsystem write up
> ----------------------------------------------------------------
>
>                 Key: WFLY-1829
>                 URL: https://issues.jboss.org/browse/WFLY-1829
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>             Fix For: 10.0.0.Final
>
>
> https://docs.jboss.org/author/display/WFLY8/EJB+Subsystem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1825) Wildfly High Availability
 Guide: Infinispan write up
In-Reply-To: <JIRA.12497986.1375719976000@Atlassian.JIRA>
References: <JIRA.12497986.1375719976000@Atlassian.JIRA>
	<JIRA.12497986.1375719976000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497986.1375719976000.13814.1443157334539@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1825:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Wildfly High Availability Guide: Infinispan write up
> ----------------------------------------------------
>
>                 Key: WFLY-1825
>                 URL: https://issues.jboss.org/browse/WFLY-1825
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.Final
>
>
> https://docs.jboss.org/author/display/WFLY8/Infinispan+Subsystem



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1725) Update The Wildfly High
	Availability Guide
In-Reply-To: <JIRA.12496926.1374260551000@Atlassian.JIRA>
References: <JIRA.12496926.1374260551000@Atlassian.JIRA>
	<JIRA.12496926.1374260551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496926.1374260551000.13820.1443157334650@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1725:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Update The Wildfly High Availability Guide 
> -------------------------------------------
>
>                 Key: WFLY-1725
>                 URL: https://issues.jboss.org/browse/WFLY-1725
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.Final
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
> https://docs.jboss.org/author/display/WFLY8/High+Availability+Guide



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1535) SSLEJBRemoteClientTestCase
 runs into intermittent failures
In-Reply-To: <JIRA.12494315.1371223824000@Atlassian.JIRA>
References: <JIRA.12494315.1371223824000@Atlassian.JIRA>
	<JIRA.12494315.1371223824000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494315.1371223824000.13825.1443157334771@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1535:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> SSLEJBRemoteClientTestCase runs into intermittent failures
> ----------------------------------------------------------
>
>                 Key: WFLY-1535
>                 URL: https://issues.jboss.org/browse/WFLY-1535
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Final
>
>
> SSLEJBRemoteClientTestCase runs into intermittent failures on TeamCity. To make matters worse, a failure in one test method can have a side effect on other test methods in that testcase, given the way it's written. The entire run is here http://teamcity.cafe-babe.org/viewLog.html?buildId=5251&tab=buildResultsDiv&buildTypeId=bt27.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1415) Move away from expensive enum
	switch
In-Reply-To: <JIRA.12493134.1369842373000@Atlassian.JIRA>
References: <JIRA.12493134.1369842373000@Atlassian.JIRA>
	<JIRA.12493134.1369842373000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493134.1369842373000.13830.1443157334906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1415:
-------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Move away from expensive enum switch
> ------------------------------------
>
>                 Key: WFLY-1415
>                 URL: https://issues.jboss.org/browse/WFLY-1415
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Priority: Minor
>              Labels: janitor
>             Fix For: 10.0.0.Final
>
>
> We use enums and enum switch extensively.  These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead.  The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes.  The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:14 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-463) Add utility for creating and
 destorying modules in tests
In-Reply-To: <JIRA.12488631.1365114411000@Atlassian.JIRA>
References: <JIRA.12488631.1365114411000@Atlassian.JIRA>
	<JIRA.12488631.1365114411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488631.1365114411000.13834.1443157334983@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-463:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Add utility for creating and destorying modules in tests
> --------------------------------------------------------
>
>                 Key: WFLY-463
>                 URL: https://issues.jboss.org/browse/WFLY-463
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Stuart Douglas
>            Assignee: Ondrej Zizka
>             Fix For: 10.0.0.Final
>
>
> Lots of tests create and destroy a static module to test functionaility involving static modules. If possible all this code should be moved into some kind of static module builder utility. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-443) Add integration test of Seam2
	integration
In-Reply-To: <JIRA.12489018.1365601723000@Atlassian.JIRA>
References: <JIRA.12489018.1365601723000@Atlassian.JIRA>
	<JIRA.12489018.1365601723000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489018.1365601723000.13839.1443157335144@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-443:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Add integration test of Seam2 integration
> -----------------------------------------
>
>                 Key: WFLY-443
>                 URL: https://issues.jboss.org/browse/WFLY-443
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>         Environment: https://github.com/jbossas/jboss-as/commit/b036d103ed503b0099d3f62c1c50f954aef03137 will break the Seam 2 integration since Seam2Processor will look for the specific jar name. Yet the commit did not result in any testsuite failure. So, it seems we have no integration testing.
>            Reporter: Brian Stansberry
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-418) TS: Move resources to source
	packages.
In-Reply-To: <JIRA.12461401.1331565661000@Atlassian.JIRA>
References: <JIRA.12461401.1331565661000@Atlassian.JIRA>
	<JIRA.12461401.1331565661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461401.1331565661000.13842.1443157335250@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-418:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> TS: Move resources to source packages.
> --------------------------------------
>
>                 Key: WFLY-418
>                 URL: https://issues.jboss.org/browse/WFLY-418
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-399) mod_cluster subsystem: convert
 operation handlers to use OperationDefinition
In-Reply-To: <JIRA.12479868.1353944133000@Atlassian.JIRA>
References: <JIRA.12479868.1353944133000@Atlassian.JIRA>
	<JIRA.12479868.1353944133000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479868.1353944133000.13846.1443157335412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-399:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> mod_cluster subsystem: convert operation handlers to use OperationDefinition
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-399
>                 URL: https://issues.jboss.org/browse/WFLY-399
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Final
>
>
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/LoadMetricDefinition.java:[59,59] warning: [deprecation] PropertiesAttributeDefinition(java.lang.String,java.lang.String,boolean) in org.jboss.as.controller.PropertiesAttributeDefinition has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[277,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[280,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[283,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[286,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterSubsystemAdd.java:[160,19] warning: [deprecation] setProxyList(java.lang.String) in org.jboss.modcluster.config.impl.ModClusterConfig has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterSubsystemAdd.java:[166,15] warning: [deprecation] setExcludedContexts(java.lang.String) in org.jboss.modcluster.config.impl.ModClusterConfig has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[100,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[103,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[106,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[110,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[113,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[117,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[120,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[124,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[127,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[130,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[134,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[137,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[140,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-366) Add support for grouping to
 Infinispan subsystem
In-Reply-To: <JIRA.12456230.1326273774000@Atlassian.JIRA>
References: <JIRA.12456230.1326273774000@Atlassian.JIRA>
	<JIRA.12456230.1326273774000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456230.1326273774000.13854.1443157335607@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-366:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Add support for grouping to Infinispan subsystem
> ------------------------------------------------
>
>                 Key: WFLY-366
>                 URL: https://issues.jboss.org/browse/WFLY-366
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Martin Gencur
>            Assignee: Tristan Tarrant
>             Fix For: 10.0.0.Final
>
>
> Enable setting of groups in Infinispan subsystem. More information about grouping can be found at https://docs.jboss.org/author/display/ISPN/The+Grouping+API.
> It should be possible to enable it as well as set a grouper class. The following is respective configuration for standalone Infinispan.
> {code:xml}
> <clustering>
>   <hash>
>      <groups enabled="true">
>         <grouper class="com.acme.KXGrouper" />
>      </groups>
>   </hash>
> </clustering>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-288) SecurityDomainJndiInjectable
 should allow "java:/jaas" prefixed security domain on demand
In-Reply-To: <JIRA.12463048.1333389594000@Atlassian.JIRA>
References: <JIRA.12463048.1333389594000@Atlassian.JIRA>
	<JIRA.12463048.1333389594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463048.1333389594000.13862.1443157335820@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-288:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-288
>                 URL: https://issues.jboss.org/browse/WFLY-288
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: 10.0.0.Final
>
>
> Currently,  security domain strings of the form "java:/jaas/sd" are not resolving properly.  IMO we should allow users to deploy applications on AS4,5,6,7 if they need to.
> So have a flag inside the SecurityDomainJndiInjectable class that is turned off by default.  If you turn it on, then "java:/jaas" is unprefixed if present.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-316) Javadoc - exclude _private.*
	packages
In-Reply-To: <JIRA.12488463.1364919092000@Atlassian.JIRA>
References: <JIRA.12488463.1364919092000@Atlassian.JIRA>
	<JIRA.12488463.1364919092000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488463.1364919092000.13858.1443157335690@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-316:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Javadoc - exclude _private.* packages
> -------------------------------------
>
>                 Key: WFLY-316
>                 URL: https://issues.jboss.org/browse/WFLY-316
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Documentation
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-277) TS: Integrate JUnitDiff
In-Reply-To: <JIRA.12460907.1331103224000@Atlassian.JIRA>
References: <JIRA.12460907.1331103224000@Atlassian.JIRA>
	<JIRA.12460907.1331103224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460907.1331103224000.13866.1443157335906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-277:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> TS: Integrate JUnitDiff
> -----------------------
>
>                 Key: WFLY-277
>                 URL: https://issues.jboss.org/browse/WFLY-277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> Running with
> {code}
> -DjunitDiff='<path1>:<path2>:<path3>'
> {code}
> would create a comparison to given testsuite result sets (JUnit .xml and txt files).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:16 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:16 -0400 (EDT)
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.13874.1443157336062@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-264:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> 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
>             Fix For: 10.0.0.Final
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:15 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-276) Clustering/multi-node tests
 cannot be run with -Djpda debugger
In-Reply-To: <JIRA.12453411.1322641838000@Atlassian.JIRA>
References: <JIRA.12453411.1322641838000@Atlassian.JIRA>
	<JIRA.12453411.1322641838000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453411.1322641838000.13870.1443157335984@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-276:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Clustering/multi-node tests cannot be run with -Djpda debugger
> --------------------------------------------------------------
>
>                 Key: WFLY-276
>                 URL: https://issues.jboss.org/browse/WFLY-276
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Documentation, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> The doc now says whats pasted below, but I am not sure if both servers are listening on 8787 because (that would fail the startup), if I have to connect to both or where do I configure that, etc.
> {code}
> Running JBoss AS instances with debugger
> Adding -Djpda (May be changed to -Ddebug in the future) will make JBoss AS run with JPDA JVM arguments for debugging.
> It will suspend and wait for the debugger to connect at port 8787.
> JBoss AS is started by Arquillian, when the first test which requires given instance is run. There's (currently) no challenge text in the console, it will look like the first test is stuck. This is being solved in http://jira.codehaus.org/browse/SUREFIRE-781.
> Depending on which test group(s) you run, multiple instances may be started. In that case, you need to attach the debugger multiple times.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:16 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-224) Add allowed values for
 attribute "cache-type" in "/subsystem=security/security-domain=*"
In-Reply-To: <JIRA.12486710.1362660680000@Atlassian.JIRA>
References: <JIRA.12486710.1362660680000@Atlassian.JIRA>
	<JIRA.12486710.1362660680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486710.1362660680000.13878.1443157336146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-224:
------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Add allowed values for attribute "cache-type" in "/subsystem=security/security-domain=*"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-224
>                 URL: https://issues.jboss.org/browse/WFLY-224
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Harald Pehl
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> The attribute "cache-type" in "/subsystem=security/security-domain=*" can either be "default" or "infinispan". Please add the allowed value to the resource description. 
> In order to generate the UI based on the management model, it is essential that information like this is present.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 01:02:16 2015
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 25 Sep 2015 01:02:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-80) Product Version should not
 prepend product name with JBoss
In-Reply-To: <JIRA.12487209.1363252404000@Atlassian.JIRA>
References: <JIRA.12487209.1363252404000@Atlassian.JIRA>
	<JIRA.12487209.1363252404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487209.1363252404000.13883.1443157336256@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-80:
-----------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR2)


> Product Version should not prepend product name with JBoss
> ----------------------------------------------------------
>
>                 Key: WFLY-80
>                 URL: https://issues.jboss.org/browse/WFLY-80
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: NadirX
>            Assignee: Jason Greene
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> version/src/main/java/org/jboss/as/version/ProductConfig.java prepends the Product Name with 'JBoss' which is inappropriate for community projects. The result is that at startup I get the following
> "INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms"
> where instead I should see 
> "INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 02:43:01 2015
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 25 Sep 2015 02:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-248) Constant pool index 268 is
	invalid
In-Reply-To: <JIRA.12577796.1436778937000@Atlassian.JIRA>
References: <JIRA.12577796.1436778937000@Atlassian.JIRA>
	<JIRA.12577796.1436778937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577796.1436778937000.13952.1443163381076@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JASSIST-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-248.
-----------------------------------
    Fix Version/s: 3.21.0-GA
       Resolution: Done


It was Javassist's compiler bug.  It could not properly compile super.m() if m is
a default method.  Please try javassist.jar available from
https://github.com/jboss-javassist/javassist


> Constant pool index 268 is invalid
> ----------------------------------
>
>                 Key: JASSIST-248
>                 URL: https://issues.jboss.org/browse/JASSIST-248
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.19.0-GA
>            Reporter: Laurent Pellegrino
>            Assignee: Shigeru Chiba
>              Labels: regression
>             Fix For: 3.21.0-GA
>
>         Attachments: _StubLinkedList.class
>
>
> We are using Javassist for one of our open source projects since about 10 years. Recently, I have tried to upgrade to version 3.19 and 3.20. Unfortunately, with both versions, generated byte code seems to cause errors with the JVM.
> Below is the output:
> {code}
> Exception in thread "RestartDownNodesPolicy node status check" java.lang.VerifyError: Illegal type at constant pool entry 268 in class pa.stub.java.util._StubLinkedList
> Exception Details:
>   Location:
>     pa/stub/java/util/_StubLinkedList.replaceAll(Ljava/util/function/UnaryOperator;)V @43: invokespecial
>   Reason:
>     Constant pool index 268 is invalid
>   Bytecode:
>     0x0000000: 2ab4 00cc 9900 252a b400 0db2 002c 100b
>     0x0000010: 32c0 0028 04bd 00ce 5903 2b53 b200 26b8
>     0x0000020: 00d7 b900 dd02 0057 b12a 2bb7 010c b1  
>   Stackmap Table:
>     same_frame(@41)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:264)
> 	at org.objectweb.proactive.core.mop.MOP.forName(MOP.java:155)
> 	at org.objectweb.proactive.core.mop.MOP.findStubConstructor(MOP.java:649)
> 	at org.objectweb.proactive.core.mop.MOP.createStubObject(MOP.java:822)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:338)
> 	at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:196)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reifyAsAsynchronous(AbstractBodyProxy.java:277)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.invokeOnBody(AbstractBodyProxy.java:154)
> 	at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reify(AbstractBodyProxy.java:123)
> 	at pa.stub.org.ow2.proactive.resourcemanager.nodesource._StubNodeSource.getDownNodes(_StubNodeSource.java)
> 	at org.ow2.proactive.resourcemanager.nodesource.policy.RestartDownNodesPolicy$1.run(RestartDownNodesPolicy.java:92)
> 	at java.util.TimerThread.mainLoop(Timer.java:555)
> 	at java.util.TimerThread.run(Timer.java:505)
> {code}
> The issue seems related to default methods introduced in Java 8. Perhaps its not an issue with Javassist but to be honest I don't understand the exception.  However, I have noticed that using Javassist in version 3.18.2 solves the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 03:51:01 2015
From: issues at jboss.org (Martin Styk (JIRA))
Date: Fri, 25 Sep 2015 03:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5407) ActiveMQ Artemis 1.1.0 in
 Wildlfy differs from upstream tag 1.1.0
In-Reply-To: <JIRA.12586094.1443167411000@Atlassian.JIRA>
References: <JIRA.12586094.1443167411000@Atlassian.JIRA>
	<JIRA.12586094.1443167411728@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586094.1443167411000.14144.1443167461193@Atlassian.JIRA>

Martin Styk created WFLY-5407:
---------------------------------

             Summary: ActiveMQ Artemis 1.1.0 in Wildlfy differs from upstream tag 1.1.0
                 Key: WFLY-5407
                 URL: https://issues.jboss.org/browse/WFLY-5407
             Project: WildFly
          Issue Type: Bug
          Components: JMS
            Reporter: Martin Styk
            Assignee: Jeff Mesnil


There are differences betweeen ActiveMQ Artemis tag 1.1.0 included in Wildlfy and Artemis tag 1.1.0 from apache/activemq-artemis Github repo.

For example
class org.apache.activemq.artemis.ra.ConnectionFactoryProperties in Artemis 1.1.0 included in Wildlfy doesn`t contain methods 
{code:java}
boolean equals(java.lang.Object)
int hashCode()
{code}

class org.apache.activemq.artemis.ra.ActiveMQResourceAdapter  in Artemis 1.1.0 included in Wildlfy doesn`t contain methods 
{code:java}
void closeConnectionFactory(org.apache.activemq.artemis.ra.ConnectionFactoryProperties)
{code}
doesn`t contain field
{code:java}
java.util.Map knownConnectionFactories
{code}




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 03:54:03 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 25 Sep 2015 03:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1007) Warnings about missing
 notification descriptions when an operation removes an extension
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.14205.1443167643508@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFCORE-1007:
--------------------------------
    Summary: Warnings about missing notification descriptions when an operation removes an extension  (was: :migrate operation shows warning "WFLYCTL0357: Notification of type resource-removed is not described" in log)


> Warnings about missing notification descriptions when an operation removes an extension
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1007
>                 URL: https://issues.jboss.org/browse/WFCORE-1007
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR4
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jeff Mesnil
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 04:40:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 04:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-905) Add protection of our
 GSSCredential added by the KerberosLoginModule
In-Reply-To: <JIRA.12582209.1440171736000@Atlassian.JIRA>
References: <JIRA.12582209.1440171736000@Atlassian.JIRA>
	<JIRA.12582209.1440171736000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582209.1440171736000.14374.1443170400652@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112413#comment-13112413 ] 

RH Bugzilla Integration commented on SECURITY-905:
--------------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 1097276|https://bugzilla.redhat.com/show_bug.cgi?id=1097276] from ON_QA to VERIFIED

> Add protection of our GSSCredential added by the KerberosLoginModule
> --------------------------------------------------------------------
>
>                 Key: SECURITY-905
>                 URL: https://issues.jboss.org/browse/SECURITY-905
>             Project: PicketBox 
>          Issue Type: Task
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_3_8_Beta1
>
>
> GSSManager implementation can have an optimisation that attempts to obtain the GSSCredential from the private credentials in the Subject, in some situations such as JDBC drivers this can mean that a driver gets direct access to the credential we are supposed to be managing the lifecycle of.
> The optimisation is based on checking if it is an instance of GSSCredentialImpl - if not then GSSManager creates a new instance.
> This Jira issue is to wrap the instance we place in the Subject to prevent the optimisation kicking in.  This then means code using the credential such as a JDBC driver is free to do what it wants with it's own credential without impacting on ours.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 04:57:00 2015
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Fri, 25 Sep 2015 04:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.14422.1443171420184@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112421#comment-13112421 ] 

Stefano Maestri commented on WFLY-5020:
---------------------------------------

Well at first look seems something wrong in jdbc service reference. My suspect is on how driver is defined/deployed. COuld you provide more info on this:

1) Are you deploying it or do you have configured ads module.
2) can you provide the full config (standalone or domain xml) or at least the full datasources subsystem
3) If you have deployed driver as jar hot deploy, could you try to configure it as module and let us know if error persist

thanks in advance
S.



> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 05:11:00 2015
From: issues at jboss.org (Thorsten Moeller (JIRA))
Date: Fri, 25 Sep 2015 05:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5366) Startup success detection
 mechanism fails if JBOSS_HOME and jboss.server.base.dir are set
 differently.
In-Reply-To: <JIRA.12585389.1442584310000@Atlassian.JIRA>
References: <JIRA.12585389.1442584310000@Atlassian.JIRA>
	<JIRA.12585389.1442584310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585389.1442584310000.14444.1443172260131@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thorsten Moeller updated WFLY-5366:
-----------------------------------
    Fix Version/s: 10.0.0.Final


> Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5366
>                 URL: https://issues.jboss.org/browse/WFLY-5366
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.CR1
>         Environment: Linux/Debian
>            Reporter: Thorsten Moeller
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.
> Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.
> I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 05:37:00 2015
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Fri, 25 Sep 2015 05:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.14507.1443173820209@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112439#comment-13112439 ] 

Hayk Hovsepyan commented on WFLY-5020:
--------------------------------------

I am directly deploying driver as jar hot deploy, standalone xml and server log are attached.
One more thing here: When I remove "<jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>" from config (but leave datasource), it deploys driver successfully.

The same problem happens for jdbc driver as module.
Log and config are attached.

> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>         Attachments: server.log, standalone.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 05:39:00 2015
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Fri, 25 Sep 2015 05:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.14523.1443173940132@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated WFLY-5020:
---------------------------------
    Attachment: server_module.log


Server log when driver is deployed as module.

> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>         Attachments: server.log, server_module.log, standalone.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 05:41:00 2015
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Fri, 25 Sep 2015 05:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.14530.1443174060147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated WFLY-5020:
---------------------------------
    Attachment: standalone_module.xml


standalone.xml when jdbc driver is deployed as module.

> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>         Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 05:42:00 2015
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Fri, 25 Sep 2015 05:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.14534.1443174120221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated WFLY-5020:
---------------------------------
    Attachment:     (was: standalone_module.xml)


> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>         Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 05:43:00 2015
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Fri, 25 Sep 2015 05:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.14540.1443174180124@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated WFLY-5020:
---------------------------------
    Comment: was deleted

(was: standalone.xml when jdbc driver is deployed as module.)


> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>         Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 06:42:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 25 Sep 2015 06:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5408) Upgrade Narayana to
	5.2.5.Final
In-Reply-To: <JIRA.12586111.1443177663000@Atlassian.JIRA>
References: <JIRA.12586111.1443177663000@Atlassian.JIRA>
	<JIRA.12586111.1443177663128@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586111.1443177663000.14637.1443177720051@Atlassian.JIRA>

Tom Jenkinson created WFLY-5408:
-----------------------------------

             Summary: Upgrade Narayana to 5.2.5.Final
                 Key: WFLY-5408
                 URL: https://issues.jboss.org/browse/WFLY-5408
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Transactions
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson
             Fix For: 10.0.0.Final






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 07:53:00 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Fri, 25 Sep 2015 07:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4237) Disabling weld in wildfly
 strangely degrade JSF performance
In-Reply-To: <JIRA.12560710.1420986147000@Atlassian.JIRA>
References: <JIRA.12560710.1420986147000@Atlassian.JIRA>
	<JIRA.12560710.1420986147000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560710.1420986147000.14884.1443181980154@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112486#comment-13112486 ] 

Dmitrii Tikhomirov commented on WFLY-4237:
------------------------------------------

yeap, productivity declined by 3-6 times, but may I ask you, why do you turned off weld ? Wildfly 9.0.0.Final and Wildfly 10.0.0.Final don't have this problem.

> Disabling weld in wildfly strangely degrade JSF performance
> -----------------------------------------------------------
>
>                 Key: WFLY-4237
>                 URL: https://issues.jboss.org/browse/WFLY-4237
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.2.0.Final
>         Environment: Windows 7 64 bit,
> Oracle JDK 1.7.60 64bit,
> Wildfly 8.2.0.Final
> JSF 2.2
>            Reporter: Mostafa Abdelkhalek
>            Assignee: Dmitrii Tikhomirov
>         Attachments: weld_disabled.png, weld_enabled.png
>
>
> The ajax response time dramatically increases by increasing the number of JSF components when weld is disabled.
> This doesn't make sense and I have no idea why does it occur
> *WELD ENABLED*
> !weld_enabled.png|thumbnail!
> *WELD DISABLED*
> !weld_disabled.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:00:02 2015
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Fri, 25 Sep 2015 08:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4237) Disabling weld in wildfly
 strangely degrade JSF performance
In-Reply-To: <JIRA.12560710.1420986147000@Atlassian.JIRA>
References: <JIRA.12560710.1420986147000@Atlassian.JIRA>
	<JIRA.12560710.1420986147000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560710.1420986147000.14899.1443182402806@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112486#comment-13112486 ] 

Dmitrii Tikhomirov edited comment on WFLY-4237 at 9/25/15 7:59 AM:
-------------------------------------------------------------------

yeap, productivity declined by 3-6 times, but may I ask you, why have you turned the weld off? Wildfly 9.0.0.Final and Wildfly 10.0.0.Final don't have this problem.


was (Author: treblereel):
yeap, productivity declined by 3-6 times, but may I ask you, why do you turned off weld ? Wildfly 9.0.0.Final and Wildfly 10.0.0.Final don't have this problem.

> Disabling weld in wildfly strangely degrade JSF performance
> -----------------------------------------------------------
>
>                 Key: WFLY-4237
>                 URL: https://issues.jboss.org/browse/WFLY-4237
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.2.0.Final
>         Environment: Windows 7 64 bit,
> Oracle JDK 1.7.60 64bit,
> Wildfly 8.2.0.Final
> JSF 2.2
>            Reporter: Mostafa Abdelkhalek
>            Assignee: Dmitrii Tikhomirov
>         Attachments: weld_disabled.png, weld_enabled.png
>
>
> The ajax response time dramatically increases by increasing the number of JSF components when weld is disabled.
> This doesn't make sense and I have no idea why does it occur
> *WELD ENABLED*
> !weld_enabled.png|thumbnail!
> *WELD DISABLED*
> !weld_disabled.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:12:00 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 25 Sep 2015 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5409) Fix KerberosTestUtils in
 testsuite - skip Kerberos tests for IPv6 if no hostname is configured
In-Reply-To: <JIRA.12586131.1443183114000@Atlassian.JIRA>
References: <JIRA.12586131.1443183114000@Atlassian.JIRA>
	<JIRA.12586131.1443183114957@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586131.1443183114000.14993.1443183120605@Atlassian.JIRA>

Josef Cacek created WFLY-5409:
---------------------------------

             Summary: Fix KerberosTestUtils in testsuite - skip Kerberos tests for IPv6 if no hostname is configured
                 Key: WFLY-5409
                 URL: https://issues.jboss.org/browse/WFLY-5409
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Josef Cacek


Condition used in {{org.jboss.as.test.integration.security.common.negotiation.KerberosTestUtils.assumeKerberosAuthenticationSupported(String)}} doesn't cover Java 8. It has to be updated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:13:00 2015
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 25 Sep 2015 08:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5409) Fix KerberosTestUtils in
 testsuite - skip Kerberos tests for IPv6 if no hostname is configured
In-Reply-To: <JIRA.12586131.1443183114000@Atlassian.JIRA>
References: <JIRA.12586131.1443183114000@Atlassian.JIRA>
	<JIRA.12586131.1443183114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586131.1443183114000.14996.1443183180113@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reassigned WFLY-5409:
---------------------------------

    Assignee: Josef Cacek


> Fix KerberosTestUtils in testsuite - skip Kerberos tests for IPv6 if no hostname is configured
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5409
>                 URL: https://issues.jboss.org/browse/WFLY-5409
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Condition used in {{org.jboss.as.test.integration.security.common.negotiation.KerberosTestUtils.assumeKerberosAuthenticationSupported(String)}} doesn't cover Java 8. It has to be updated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:35:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 08:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5409) Fix KerberosTestUtils in
 testsuite - skip Kerberos tests for IPv6 if no hostname is configured
In-Reply-To: <JIRA.12586131.1443183114000@Atlassian.JIRA>
References: <JIRA.12586131.1443183114000@Atlassian.JIRA>
	<JIRA.12586131.1443183114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586131.1443183114000.15045.1443184500221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-5409:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1266482
        Bugzilla Update: Perform


> Fix KerberosTestUtils in testsuite - skip Kerberos tests for IPv6 if no hostname is configured
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5409
>                 URL: https://issues.jboss.org/browse/WFLY-5409
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Condition used in {{org.jboss.as.test.integration.security.common.negotiation.KerberosTestUtils.assumeKerberosAuthenticationSupported(String)}} doesn't cover Java 8. It has to be updated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:46:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Fri, 25 Sep 2015 08:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5410) jboss-web_10_0.xsd is
	inccorect
In-Reply-To: <JIRA.12586139.1443185101000@Atlassian.JIRA>
References: <JIRA.12586139.1443185101000@Atlassian.JIRA>
	<JIRA.12586139.1443185101670@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586139.1443185101000.15070.1443185160136@Atlassian.JIRA>

ehsavoie Hugonnet created WFLY-5410:
---------------------------------------

             Summary: jboss-web_10_0.xsd is inccorect
                 Key: WFLY-5410
                 URL: https://issues.jboss.org/browse/WFLY-5410
             Project: WildFly
          Issue Type: Bug
          Components: Documentation
    Affects Versions: 10.0.0.CR2
            Reporter: ehsavoie Hugonnet
            Assignee: Eduardo Martins


jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:47:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Fri, 25 Sep 2015 08:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-389) Missing jboss_commons_7_0.xsd
In-Reply-To: <JIRA.12586140.1443185185000@Atlassian.JIRA>
References: <JIRA.12586140.1443185185000@Atlassian.JIRA>
	<JIRA.12586140.1443185185481@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586140.1443185185000.15080.1443185220326@Atlassian.JIRA>

ehsavoie Hugonnet created JBMETA-389:
----------------------------------------

             Summary: Missing jboss_commons_7_0.xsd
                 Key: JBMETA-389
                 URL: https://issues.jboss.org/browse/JBMETA-389
             Project: JBoss Metadata
          Issue Type: Bug
          Components: web
    Affects Versions: 10.0.0.Beta1
            Reporter: ehsavoie Hugonnet
            Assignee: Jean-Frederic Clere


jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:48:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Fri, 25 Sep 2015 08:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-389) Missing jboss_commons_7_0.xsd
In-Reply-To: <JIRA.12586140.1443185185000@Atlassian.JIRA>
References: <JIRA.12586140.1443185185000@Atlassian.JIRA>
	<JIRA.12586140.1443185185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586140.1443185185000.15091.1443185280288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBMETA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned JBMETA-389:
----------------------------------------

    Assignee: Eduardo Martins  (was: Jean-Frederic Clere)


> Missing jboss_commons_7_0.xsd
> -----------------------------
>
>                 Key: JBMETA-389
>                 URL: https://issues.jboss.org/browse/JBMETA-389
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 10.0.0.Beta1
>            Reporter: ehsavoie Hugonnet
>            Assignee: Eduardo Martins
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:52:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Fri, 25 Sep 2015 08:52:00 -0400 (EDT)
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.15100.1443185520287@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5400:
---------------------------------
    Priority: Major  (was: Blocker)


> 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: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: Clebert Suconic
>         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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:52:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Fri, 25 Sep 2015 08:52:00 -0400 (EDT)
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.15103.1443185520341@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-5400:
---------------------------------
    Component/s: Documentation


> 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: Clebert Suconic
>         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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:54:01 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Fri, 25 Sep 2015 08:54:01 -0400 (EDT)
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.15148.1443185641299@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112508#comment-13112508 ] 

Miroslav Novak commented on WFLY-5400:
--------------------------------------

After discussion with dev there was misconfiguration in standalone.xml. There must be same connector in connection factory for client and in cluster-connection. This thing will be documented.


> 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: Clebert Suconic
>         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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 08:55:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Fri, 25 Sep 2015 08:55:00 -0400 (EDT)
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.15156.1443185700370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak reassigned WFLY-5400:
------------------------------------

    Assignee: Deon Ballard  (was: Clebert Suconic)


> 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: Deon Ballard
>         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
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 09:10:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 25 Sep 2015 09:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5411) add support for MQTT protocol
In-Reply-To: <JIRA.12586143.1443186559000@Atlassian.JIRA>
References: <JIRA.12586143.1443186559000@Atlassian.JIRA>
	<JIRA.12586143.1443186559864@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586143.1443186559000.15283.1443186600057@Atlassian.JIRA>

Jeff Mesnil created WFLY-5411:
---------------------------------

             Summary: add support for MQTT protocol
                 Key: WFLY-5411
                 URL: https://issues.jboss.org/browse/WFLY-5411
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 11.0.0.Alpha1


Artemis now supports MQTT.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 09:39:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 25 Sep 2015 09:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5366) Startup success detection
 mechanism fails if JBOSS_HOME and jboss.server.base.dir are set
 differently.
In-Reply-To: <JIRA.12585389.1442584310000@Atlassian.JIRA>
References: <JIRA.12585389.1442584310000@Atlassian.JIRA>
	<JIRA.12585389.1442584310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585389.1442584310000.15359.1443188340251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-5366:
-----------------------------------
    Priority: Major  (was: Critical)


> Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5366
>                 URL: https://issues.jboss.org/browse/WFLY-5366
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.CR1
>         Environment: Linux/Debian
>            Reporter: Thorsten Moeller
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Final
>
>
> If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.
> Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.
> I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 09:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 25 Sep 2015 09:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5366) Startup success detection
 mechanism fails if JBOSS_HOME and jboss.server.base.dir are set
 differently.
In-Reply-To: <JIRA.12585389.1442584310000@Atlassian.JIRA>
References: <JIRA.12585389.1442584310000@Atlassian.JIRA>
	<JIRA.12585389.1442584310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585389.1442584310000.15366.1443188400295@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-5366:
-----------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


> Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5366
>                 URL: https://issues.jboss.org/browse/WFLY-5366
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.CR1
>         Environment: Linux/Debian
>            Reporter: Thorsten Moeller
>            Assignee: Tomaz Cerar
>
> If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.
> Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.
> I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 09:58:00 2015
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Fri, 25 Sep 2015 09:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently. Allow idle thread reusage.
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.15426.1443189480212@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos updated WFLY-5332:
------------------------------------------
    Attachment: ModifiedJBossThreadPoolExecutorStateDiagram.jpg


Adding the Modified JBoss Thread Pool Executor State Diagram.

> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>         Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new 
> thread [up until max-threads]."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 10:40:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4423) ClassNotFoundException:
 org.jboss.naming.remote.client.InitialContextFactory
In-Reply-To: <JIRA.12565707.1426177059000@Atlassian.JIRA>
References: <JIRA.12565707.1426177059000@Atlassian.JIRA>
	<JIRA.12565707.1426177059000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565707.1426177059000.15645.1443192000665@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112568#comment-13112568 ] 

RH Bugzilla Integration commented on WFLY-4423:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1201358|https://bugzilla.redhat.com/show_bug.cgi?id=1201358] from ON_QA to VERIFIED

> ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-4423
>                 URL: https://issues.jboss.org/browse/WFLY-4423
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 9.0.0.Beta1
>
>
> To reproduce this issue follow the steps:
>  - setup JMS bridge between two WildFly instances
>  - once JMS bridge is running, login into jboss-cli and stop the bridge
>  - restart the bridge fro jboss-cli
> The following exception appears in the serve log file.
> 10:12:59,414 INFO  [org.hornetq.jms.server] (pool-9-thread-1) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 60,000 ms
> 10:13:59,416 WARN  [org.hornetq.jms.server] (pool-9-thread-1) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.naming.remote.client.InitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:126)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_75]
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_75]
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_75]
> 	at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_75]
> 	at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_75]
> 	at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55)
> 	at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1236)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1474)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2200(JMSBridgeImpl.java:79)
> 	at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2082)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: java.lang.ClassNotFoundException: org.jboss.naming.remote.client.InitialContextFactory from [Module "org.jboss.as.controller:main" from local module loader @543a2dec (finder: local module finder @379d0c27 (roots: /Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules,/Volumes/RedHat/Work/JBoss/EAP/JBoss-6/current/home/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.5.Final-redhat-1]
> 	at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_75]
> 	at java.lang.Class.forName(Class.java:274) [rt.jar:1.7.0_75]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:121)
> 	... 17 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 10:49:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 10:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-921) Drools fires no rules with
 this Drools/CEP test
In-Reply-To: <JIRA.12585301.1442523320000@Atlassian.JIRA>
References: <JIRA.12585301.1442523320000@Atlassian.JIRA>
	<JIRA.12585301.1442523320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585301.1442523320000.15718.1443192540529@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112573#comment-13112573 ] 

RH Bugzilla Integration commented on DROOLS-921:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1218291|https://bugzilla.redhat.com/show_bug.cgi?id=1218291] from ASSIGNED to MODIFIED

> Drools fires no rules with this Drools/CEP test
> -----------------------------------------------
>
>                 Key: DROOLS-921
>                 URL: https://issues.jboss.org/browse/DROOLS-921
>             Project: Drools
>          Issue Type: Bug
>            Reporter: David Weir
>            Assignee: Mario Fusco
>             Fix For: 6.3.0.Final
>
>         Attachments: DroolsLoopingTest.java, MyMessage.java
>
>
> I'm debugging a looping test and when I run the attached, it fires no rules



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 10:49:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 10:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-751) Different threads accessing
 LeftTuple fields that reference LeftTupleSet
In-Reply-To: <JIRA.12567019.1427387255000@Atlassian.JIRA>
References: <JIRA.12567019.1427387255000@Atlassian.JIRA>
	<JIRA.12567019.1427387255000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567019.1427387255000.15724.1443192540630@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112574#comment-13112574 ] 

RH Bugzilla Integration commented on DROOLS-751:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1218291|https://bugzilla.redhat.com/show_bug.cgi?id=1218291] from ASSIGNED to MODIFIED

> Different threads accessing LeftTuple fields that reference LeftTupleSet
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-751
>                 URL: https://issues.jboss.org/browse/DROOLS-751
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.3.0.Beta1
>
>
> In class LeftTupleSetsImpl there are missing nullchecks in some methods that contains handling LeftTuple instances. I.e. in method removeInsert there is LeftTuple variable previous that is not nullchecked.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 10:51:00 2015
From: issues at jboss.org (Matthieu Brouillard (JIRA))
Date: Fri, 25 Sep 2015 10:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5351) querying TimerService
 information from CLI fails for canceled timer
In-Reply-To: <JIRA.12585051.1442389327000@Atlassian.JIRA>
References: <JIRA.12585051.1442389327000@Atlassian.JIRA>
	<JIRA.12585051.1442389327000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585051.1442389327000.15735.1443192660128@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthieu Brouillard updated WFLY-5351:
--------------------------------------
    Affects Version/s: 10.0.0.CR2


I just tested with latest `10.0.0.CR2` and the problem still exists.

> querying TimerService information from CLI fails for canceled timer
> -------------------------------------------------------------------
>
>                 Key: WFLY-5351
>                 URL: https://issues.jboss.org/browse/WFLY-5351
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.1.Final, 10.0.0.CR2
>         Environment: probably not relevant but here is my environment
> {{Java Version     : 1.8.0_60
> Java Vendor      : Oracle Corporation
> OS Hostname      : PAMWX125
> OS Architecture  : amd64
> OS Name          : Windows 7
> }}
>            Reporter: Matthieu Brouillard
>         Attachments: patch1.diff, timer-cli-failure.zip
>
>
> When (at least) a persistent calendar timer is created then cancelled, querying TimerService information via CLI (script or library) fails when retrieving also runtime information.
> We discovered the issue because our arquillian tests are failing due to some code in arquillian that fires the equivalent of the provided CLI command below when remotes tests are executed.
> Attached is a proposed patch and a demo project to reproduce in a simple way.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:16:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 11:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1060) When starting JBoss AS -b
 should work no matter how I start JBoss AS to bind it to the local
 interface
In-Reply-To: <JIRA.12469850.1341334879000@Atlassian.JIRA>
References: <JIRA.12469850.1341334879000@Atlassian.JIRA>
	<JIRA.12469850.1341334879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469850.1341334879000.15963.1443194160288@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112602#comment-13112602 ] 

RH Bugzilla Integration commented on WFLY-1060:
-----------------------------------------------

Marek Kopecky <mkopecky at redhat.com> changed the Status of [bug 1125025|https://bugzilla.redhat.com/show_bug.cgi?id=1125025] from ON_QA to VERIFIED

> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1060
>                 URL: https://issues.jboss.org/browse/WFLY-1060
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>              Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address.  Instead it binds to localhost 127.0.0.1.  It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-925) Cannot deploy kie-server to
 Wildfly 10.0.0.CR1
In-Reply-To: <JIRA.12585580.1442862774000@Atlassian.JIRA>
References: <JIRA.12585580.1442862774000@Atlassian.JIRA>
	<JIRA.12585580.1442862774000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585580.1442862774000.16061.1443194522033@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-925:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Cannot deploy kie-server to Wildfly 10.0.0.CR1
> ----------------------------------------------
>
>                 Key: DROOLS-925
>                 URL: https://issues.jboss.org/browse/DROOLS-925
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR2
>         Environment: Wildfly 10.0.0.CR1
>            Reporter: Pokpitch Patcharadamrongkul
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 6.4.x
>
>
> Cannot deploy kie-server to Wildfly 10.0.0.CR1 (HornetQ is to be deprecated from Wildfly 10.x.x) Please fixed in kie-server-x.x-x.war/META-INF/kie-server-jms.xml
> {color:red}Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /opt/wildfly-10.0.0.CR1/standalone/tmp/vfs/temp/temp8eb8a1f894857057/content-c7b7cd6a0a56658e/META-INF/kie-server-jms.xml
> 	at org.wildfly.extension.messaging.activemq.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95)
> 	... 6 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
> Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.wildfly.extension.messaging.activemq.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89)
> 	... 6 more{color}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-910) Kie Navigator Server
 Property dialog does not save user creds
In-Reply-To: <JIRA.12584414.1441808297000@Atlassian.JIRA>
References: <JIRA.12584414.1441808297000@Atlassian.JIRA>
	<JIRA.12584414.1441808297000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584414.1441808297000.16065.1443194522107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-910:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Kie Navigator Server Property dialog does not save user creds
> -------------------------------------------------------------
>
>                 Key: DROOLS-910
>                 URL: https://issues.jboss.org/browse/DROOLS-910
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 6.3.0.CR2
>            Reporter: Robert (Bob) Brodt
>            Assignee: Robert (Bob) Brodt
>             Fix For: 6.4.x
>
>
> The Server Property dialog from Kie Navigator view does not save the username/password information and always defaults to admin/admin.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-855) Migrating
 DroolsJaxbHelperImpl from XJC/CodeModel code to a different framework
In-Reply-To: <JIRA.12578925.1437571225000@Atlassian.JIRA>
References: <JIRA.12578925.1437571225000@Atlassian.JIRA>
	<JIRA.12578925.1437571225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578925.1437571225000.16068.1443194522166@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-855:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Migrating DroolsJaxbHelperImpl from XJC/CodeModel code to a different framework
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-855
>                 URL: https://issues.jboss.org/browse/DROOLS-855
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Beta2
>            Reporter: Marco Rietveld
>            Assignee: Marco Rietveld
>             Fix For: 6.4.x
>
>
> The {{DroolsJaxbHelperProviderImpl}} class uses classes from the {{com.sun.codemodel.\*}} and {{com.sun.tools.xjc.\*}} packages, which interferes with an upgrade to a newer version of CXF. 
> This jira is for the migration of that code (primarily the {{addXsdModel(..)}} method) to a different framework. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-817) Extremely poor performance
 of the topological sorting implementation for type declarations performs
In-Reply-To: <JIRA.12574901.1434234948000@Atlassian.JIRA>
References: <JIRA.12574901.1434234948000@Atlassian.JIRA>
	<JIRA.12574901.1434234948000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574901.1434234948000.16071.1443194522225@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-817:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Extremely poor performance of the topological sorting implementation for type declarations performs 
> ----------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-817
>                 URL: https://issues.jboss.org/browse/DROOLS-817
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 6.4.x
>
>
> The current implementation suffers from thrashing.
> In case of large business object models (e.g. derived from an ontology), 
> the analysis at package build time may take orders of magnitude more 
> than necessary



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-744) Rule Generation Feature
	Request
In-Reply-To: <JIRA.12566202.1426647181000@Atlassian.JIRA>
References: <JIRA.12566202.1426647181000@Atlassian.JIRA>
	<JIRA.12566202.1426647181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566202.1426647181000.16075.1443194522303@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-744:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Rule Generation Feature Request
> -------------------------------
>
>                 Key: DROOLS-744
>                 URL: https://issues.jboss.org/browse/DROOLS-744
>             Project: Drools
>          Issue Type: Feature Request
>          Components: core engine, kie server
>    Affects Versions: 6.2.0.Final
>            Reporter: Justin Holmes
>            Assignee: Mario Fusco
>             Fix For: 6.4.x
>
>
> As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems. 
> The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-733) Unify Drools and jBPM
	execution servers
In-Reply-To: <JIRA.12564821.1425478015000@Atlassian.JIRA>
References: <JIRA.12564821.1425478015000@Atlassian.JIRA>
	<JIRA.12564821.1425478015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564821.1425478015000.16081.1443194522412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-733:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Unify Drools and jBPM execution servers
> ---------------------------------------
>
>                 Key: DROOLS-733
>                 URL: https://issues.jboss.org/browse/DROOLS-733
>             Project: Drools
>          Issue Type: Feature Request
>          Components: kie server
>    Affects Versions: 6.2.0.Final
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 6.4.x
>
>
> This is a placeholder parent ticket for the merge of the code from Drools and jBPM execution servers into a single server.
> The new server should be standalone, free of UI code, support remote interfaces, and comply to all requirements from both Drools and jBPM.
> It should try to avoid the use of technologies that cause issues on different containers (like CDI), and be as lightweight as possible for cloud deployment.
> Initial open questions include:
> * support to databases and persistence: should this be a per-container configuration or per-kjar configuration?
> * can a single deployment model be used for both drools and jbpm?
> * how to apply the security model from jbpm? 
> * does the workbench need to continue to support remote REST calls for deployments or can it be moved completely out of it?
> * workbench UI consolidation for exec servers



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-709) fuse-bxms-integ list of
 build/release issues
In-Reply-To: <JIRA.12562849.1423582037000@Atlassian.JIRA>
References: <JIRA.12562849.1423582037000@Atlassian.JIRA>
	<JIRA.12562849.1423582037000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562849.1423582037000.16085.1443194522532@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-709:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> fuse-bxms-integ list of build/release issues
> --------------------------------------------
>
>                 Key: DROOLS-709
>                 URL: https://issues.jboss.org/browse/DROOLS-709
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 6.4.x
>
>
> Here's a summary of the issues discussed in e-mail so we can track them.
> 1) fuse-bxms-integ violates Red Hat naming:
> We can't use a product name ("Fuse", "bxms") for community code.
> The repository contains community glue code between camel and kie,
> so for example "camel-kie-integ" would be better.
> Is drools-camel open source?
> If yes, then we want the community to be able to use it and report issues before we release the product version.
> 2) The artifacts of fuse-bxms-integ all still use the groupId "org.kie",
> but supposedly have their a different version numbering than org.kie's artifacts.
> 2 artifacts in the same groupId must use the exact same version numbering and release lifecycle!
> So the groupId must be changed before its released.
> 3) fuse-bxms-integ will use it's own version numbering, so it should not use kie's "6.2.0.Final"
> Either it uses a neutral number, such as "1.0.0.Final"
> or it defines a pattern based on it's kie and it's camel dependency. For example "6.2.0.Final-2.14.1.Final" (bad example, violates OSGi guidelines).
> Calling it "6.2.0.Final" is just asking for confusion and trouble,
> because productization scripts will presume it's 100% equal to the kie version.
> 4) Now one seems to have the faintest idea how we'll handle branching: think camel 2.14.x, camel 2.13.x, kie 6.2.x, camel 2.12.x, kie 6.1.x, ...
> 5) // Not valid
> 6) Renaming the java packages according to the new groupId/artifactId we will choose (as we did in the past with all other projects) and also fix the OSGi manifest and features.xml files accordingly.
> 7) migrating the optaplanner-camel module in the new integration project.
> Note: ge0ffrey will migrate optaplanner-camel after the other issues in this list are solved to avoid breaking users now.
> 8) It's artifacts are currently:
> - no longer extending droolsjbpm-parent(-with-dependencies)
> - no longer in the kie-bom
> and that the repo is no longer in our github organization or git-clone-others script, but it is part of our release.
> So it's already quite different than in 6.1.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-680) "contains" operator behaves
 inconsistently when used with Maps
In-Reply-To: <JIRA.12560583.1420792236000@Atlassian.JIRA>
References: <JIRA.12560583.1420792236000@Atlassian.JIRA>
	<JIRA.12560583.1420792236000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560583.1420792236000.16089.1443194522606@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-680:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> "contains" operator behaves inconsistently when used with Maps
> --------------------------------------------------------------
>
>                 Key: DROOLS-680
>                 URL: https://issues.jboss.org/browse/DROOLS-680
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.4.x
>
>
> In a rule
> {code}
> Bean( map contains "x" ) // assuming "map" is a property of type Map
> {code}
> "contains" is arbitrarily interpreted as "containsKey"
> The constrain will then fail after being jitted
> The documentation explicitly states that "contains" applies to collections



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-670) Generalize inline casts to
 work with traits
In-Reply-To: <JIRA.12559527.1418604958000@Atlassian.JIRA>
References: <JIRA.12559527.1418604958000@Atlassian.JIRA>
	<JIRA.12559527.1418604958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559527.1418604958000.16092.1443194522687@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-670:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Generalize inline casts to work with traits
> -------------------------------------------
>
>                 Key: DROOLS-670
>                 URL: https://issues.jboss.org/browse/DROOLS-670
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 6.2.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>             Fix For: 6.4.x
>
>
> The following constraint
> {code}
> Person( this#Worker( wage > 1000 ) )
> {code}
> is admissible when Worker is a subtype of Person.
> It should also be possible to use "#" when Worker is a donned trait.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:02 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-669) Create "behavesAs" operator
 to support traiting
In-Reply-To: <JIRA.12559526.1418604821000@Atlassian.JIRA>
References: <JIRA.12559526.1418604821000@Atlassian.JIRA>
	<JIRA.12559526.1418604821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559526.1418604821000.16096.1443194522797@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-669:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Create "behavesAs" operator to support traiting
> -----------------------------------------------
>
>                 Key: DROOLS-669
>                 URL: https://issues.jboss.org/browse/DROOLS-669
>             Project: Drools
>          Issue Type: Feature Request
>    Affects Versions: 6.2.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>             Fix For: 6.4.x
>
>
> Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:03 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-607) Match.getObjects() should
 reflect the patterns' order
In-Reply-To: <JIRA.12552849.1411313397000@Atlassian.JIRA>
References: <JIRA.12552849.1411313397000@Atlassian.JIRA>
	<JIRA.12552849.1411313397000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552849.1411313397000.16101.1443194523022@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-607:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Match.getObjects() should reflect the patterns' order
> -----------------------------------------------------
>
>                 Key: DROOLS-607
>                 URL: https://issues.jboss.org/browse/DROOLS-607
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.1.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Minor
>             Fix For: 6.4.x
>
>
> if Match.getObjects() is called on a rule with LHS A() B() C(), 
> the resulting list will have the matching objects in reversed order 
> - that is, [c, b, a] - making it more difficult to analyze it. 
> The object's position in the list should reflect the LHS. 
> The order should be preserved even when subnetworks are present.
> For example, A() not B() C() should then result in the list [a, *, c ]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:03 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-542) Expose more Commands through
 the KieCommands API
In-Reply-To: <JIRA.12545563.1404400105000@Atlassian.JIRA>
References: <JIRA.12545563.1404400105000@Atlassian.JIRA>
	<JIRA.12545563.1404400105000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545563.1404400105000.16105.1443194523104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-542:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Expose more Commands through the KieCommands API
> ------------------------------------------------
>
>                 Key: DROOLS-542
>                 URL: https://issues.jboss.org/browse/DROOLS-542
>             Project: Drools
>          Issue Type: Feature Request
>    Affects Versions: 6.1.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>             Fix For: 6.4.x
>
>
> Not all Commands are exposed by the KieCommands API interface



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:03 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-470) Decision Table (XLS) should
 support fixed conditions, such as SeatDesignation(isNeighborOf($guest))
In-Reply-To: <JIRA.12538885.1398256310000@Atlassian.JIRA>
References: <JIRA.12538885.1398256310000@Atlassian.JIRA>
	<JIRA.12538885.1398256310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538885.1398256310000.16109.1443194523169@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-470:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest))
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-470
>                 URL: https://issues.jboss.org/browse/DROOLS-470
>             Project: Drools
>          Issue Type: Enhancement
>          Components: decision tables
>    Affects Versions: 6.1.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Anstis
>              Labels: optaplanner-request-for-drools
>             Fix For: 6.4.x
>
>
> This DT should work:
> ||CONDITION||CONDITION||ACTION|
> |$guest : SeatDesignation()|$neighbor : SeatDesignation(isNeighborOf($guest))||
> |guestName == "$param"|guestName == "$param"|doSomething();|
> It crashes because of the "SeatDesignation(isNeighborOf($guest))". Only empty parenthesis are allowed.
> Failing workaround 1: This workaround (as specified by the docs), does NOT work well, because it adds the same condition (isNeighborOf($guest)) multiple times in the same rule:
> ||CONDITION||CONDITION||CONDITION||ACTION|
> |$guest : SeatDesignation()|$neighbor : SeatDesignation()|||
> |guestName == "$param"|isNeighborOf($guest), guestName == "$param"|isNeighborOf($guest), guestAge == "$param"|doSomething();|
> Failing workaround 2: Adding an extra, hidden column with that condition does not work when new rows are added because condition columns with an empty cell are ignored.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:22:03 2015
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Fri, 25 Sep 2015 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-453) Allow KieSession globals
 configurable via kmodule.xml
In-Reply-To: <JIRA.12534852.1394701072000@Atlassian.JIRA>
References: <JIRA.12534852.1394701072000@Atlassian.JIRA>
	<JIRA.12534852.1394701072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534852.1394701072000.16115.1443194523272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-453:
------------------------------------------
    Fix Version/s: 6.4.x
                       (was: 6.3.0.Final)


> Allow KieSession globals configurable via kmodule.xml
> -----------------------------------------------------
>
>                 Key: DROOLS-453
>                 URL: https://issues.jboss.org/browse/DROOLS-453
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 6.0.0.Final
>            Reporter: Anton Giertli
>            Assignee: Mark Proctor
>             Fix For: 6.4.x
>
>
> Looking at the current xsd of kmodule.xml
> https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.0.x/kie-api/src/main/resources/org/kie/api/kmodule.xsd
> It is not possible to configure KieSession globals variables via kmodule.xml.
> Given the fact it is already possible to configure almost every KieSession related features like listeners, handlers, loggers, globals, also session related, should be configurable through the kmodule.xml too.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:40:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 25 Sep 2015 11:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1007) Warnings about missing
 notification descriptions when an operation removes an extension
In-Reply-To: <JIRA.12585895.1443077111000@Atlassian.JIRA>
References: <JIRA.12585895.1443077111000@Atlassian.JIRA>
	<JIRA.12585895.1443077111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585895.1443077111000.16256.1443195600398@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1007:
-------------------------------------
    Fix Version/s: 2.0.0.CR6


> Warnings about missing notification descriptions when an operation removes an extension
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1007
>                 URL: https://issues.jboss.org/browse/WFCORE-1007
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR4
>            Reporter: Ond?ej Chaloupka
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0.CR6
>
>
> When I use migration operation the console log is filled with warning messages of type
> {{WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]}}
> This is the same either for jacorb or web or messaging subsystem. If I do the sequence of operation
> {code}
> [standalone at localhost:9999 /] /subsystem=jacorb:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=messaging:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> [standalone at localhost:9999 /] /subsystem=we
> web  webservices  weld  
> [standalone at localhost:9999 /] /subsystem=web
> web  webservices  
> [standalone at localhost:9999 /] /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> then I the log looks like
> {code}
> 2015-09-24 08:41:09,729 WARN  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "jacorb")]
> 2015-09-24 08:43:13,229 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "DLQ")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("jms-queue" => "ExpiryQueue")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("pooled-connection-factory" => "hornetq-ra")
> ]
> 2015-09-24 08:43:13,230 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "InVmConnectionFactory")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("address-setting" => "#")
> ]
> 2015-09-24 08:43:13,231 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#"),
>     ("role" => "guest")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("security-setting" => "#")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-acceptor" => "in-vm")
> ]
> 2015-09-24 08:43:13,232 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "direct-deliver")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,233 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-acceptor" => "netty")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("in-vm-connector" => "in-vm")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput"),
>     ("param" => "batch-delay")
> ]
> 2015-09-24 08:43:13,234 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty-throughput")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("remote-connector" => "netty")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]
> 2015-09-24 08:43:13,235 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "messaging")]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "jsp-configuration")
> ]
> 2015-09-24 08:43:20,957 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "static-resources")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("configuration" => "container")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("virtual-server" => "default-host")
> ]
> 2015-09-24 08:43:20,958 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [
>     ("subsystem" => "web"),
>     ("connector" => "http")
> ]
> 2015-09-24 08:43:20,959 WARN  [org.jboss.as.controller] (management-handler-thread - 7) WFLYCTL0357: Notification of type resource-removed is not described for the resource at the address [("subsystem" => "web")]
> {code}
> I think that the migration operation should not show those warnings.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 11:42:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 25 Sep 2015 11:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4937) Implement graceful shutdown
 for transactions
In-Reply-To: <JIRA.12578249.1437039319000@Atlassian.JIRA>
References: <JIRA.12578249.1437039319000@Atlassian.JIRA>
	<JIRA.12578249.1437039319000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578249.1437039319000.16268.1443195720468@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-4937:
--------------------------------
    Fix Version/s:     (was: 11.0.0.Alpha1)


> Implement graceful shutdown for transactions
> --------------------------------------------
>
>                 Key: WFLY-4937
>                 URL: https://issues.jboss.org/browse/WFLY-4937
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>
> We will handle suspend for JTA and JTS by disallowing new transactions and then block the suspend thread until the count of active transactions drops to zero. We will also suspend the recovery manager.
> We will *not* do graceful shutdown for the optional XTS subsystem. For example an incoming XTS request for an existing transaction will be blocked. 
> Question: should we
> - raise a new JIRA for this XTS case;
> - document the deficiency and see if there are complaints;
> - document the deficiency and fix it in a subsequent release



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:42:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 25 Sep 2015 11:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5069) Missing service to represent
 the TransactionListenerRegistry
In-Reply-To: <JIRA.12580609.1438940968000@Atlassian.JIRA>
References: <JIRA.12580609.1438940968000@Atlassian.JIRA>
	<JIRA.12580609.1438940968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580609.1438940968000.16273.1443195720573@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5069:
--------------------------------
    Fix Version/s:     (was: 11.0.0.Alpha1)


> Missing service to represent the TransactionListenerRegistry
> ------------------------------------------------------------
>
>                 Key: WFLY-5069
>                 URL: https://issues.jboss.org/browse/WFLY-5069
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>
> JBTM-2343 added an observer SPI for tracking transaction state association changes for use by the JPA subsystem. This needs to be available as a wildfly service for consumption by other subsystems (currently JPA casts the TM to get hold of the TransactionListenerRegistry).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:43:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 25 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.16282.1443195780546@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5020:
--------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: 10.0.0.CR1)


> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Final
>
>         Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:43:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 25 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.16286.1443195780622@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5020:
--------------------------------
    Priority: Blocker  (was: Major)


> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>         Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 11:43:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 25 Sep 2015 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5412) IIOP migrate operation
 missing warning if on/off elements are in default (deactivated) state
In-Reply-To: <JIRA.12586174.1443195759000@Atlassian.JIRA>
References: <JIRA.12586174.1443195759000@Atlassian.JIRA>
	<JIRA.12586174.1443195759579@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586174.1443195759000.16289.1443195780757@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5412:
--------------------------------------

             Summary: IIOP migrate operation missing warning if on/off elements are in default (deactivated) state
                 Key: WFLY-5412
                 URL: https://issues.jboss.org/browse/WFLY-5412
             Project: WildFly
          Issue Type: Bug
          Components: IIOP
            Reporter: Ond?ej Chaloupka
            Assignee: Tomasz Adamski


I've mentioned that I'm missing migrate warnings for {{jacorb}} subsystem when values are in default (deactivated state). E.g. this configuration won't show any migration warning despite it should as non-supported values are used

{code}
        <subsystem xmlns="urn:jboss:domain:jacorb:2.0">
            <orb cache-poa-names="off" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
                <initializers security="identity" transactions="spec"/>
            </orb>
            <poa monitoring="off"/>
            <interop sun="on" chunk-custom-rmi-valuetypes="off"/>
        </subsystem>
{code}

if e.g. I set {{monitoring="on"}} then the warning is shown.

*Additionally*
there seems to be mistake for {{sun}} property because setting {{sun="off"}} will case that warning will be shown in this way
{code}
"WFLYORB0132: Properties [monitoring] cannot be emulated using OpenJDK ORB and are not supported"
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 11:44:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 25 Sep 2015 11:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5412) IIOP migrate operation
 missing warning if on/off elements are in default (deactivated) state
In-Reply-To: <JIRA.12586174.1443195759000@Atlassian.JIRA>
References: <JIRA.12586174.1443195759000@Atlassian.JIRA>
	<JIRA.12586174.1443195759000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586174.1443195759000.16292.1443195840097@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5412:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> IIOP migrate operation missing warning if on/off elements are in default (deactivated) state
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5412
>                 URL: https://issues.jboss.org/browse/WFLY-5412
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>
> I've mentioned that I'm missing migrate warnings for {{jacorb}} subsystem when values are in default (deactivated state). E.g. this configuration won't show any migration warning despite it should as non-supported values are used
> {code}
>         <subsystem xmlns="urn:jboss:domain:jacorb:2.0">
>             <orb cache-poa-names="off" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
>                 <initializers security="identity" transactions="spec"/>
>             </orb>
>             <poa monitoring="off"/>
>             <interop sun="on" chunk-custom-rmi-valuetypes="off"/>
>         </subsystem>
> {code}
> if e.g. I set {{monitoring="on"}} then the warning is shown.
> *Additionally*
> there seems to be mistake for {{sun}} property because setting {{sun="off"}} will case that warning will be shown in this way
> {code}
> "WFLYORB0132: Properties [monitoring] cannot be emulated using OpenJDK ORB and are not supported"
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 11:50:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 25 Sep 2015 11:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5413) On IIOP migration default
 properties are not persisted
In-Reply-To: <JIRA.12586176.1443196181000@Atlassian.JIRA>
References: <JIRA.12586176.1443196181000@Atlassian.JIRA>
	<JIRA.12586176.1443196181475@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586176.1443196181000.16305.1443196200604@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5413:
--------------------------------------

             Summary: On IIOP migration default properties are not persisted
                 Key: WFLY-5413
                 URL: https://issues.jboss.org/browse/WFLY-5413
             Project: WildFly
          Issue Type: Bug
          Components: IIOP
            Reporter: Ond?ej Chaloupka
            Assignee: Tomasz Adamski


If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such  property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML.

It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly.

The example of such properties which do not persist because of its default values are
* initializers: security="none"
* security: client-supports="ServerAuth" server-supports="MutualAuth" 
* security: client-requires="None" server-requires="None"
* transport-config: detect-misordering="none"
* as-context: auth-method="username_password" required="false"
* sas-context caller-propagation="none"
 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 11:50:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 25 Sep 2015 11:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5413) On IIOP migration default
 properties are not persisted
In-Reply-To: <JIRA.12586176.1443196181000@Atlassian.JIRA>
References: <JIRA.12586176.1443196181000@Atlassian.JIRA>
	<JIRA.12586176.1443196181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586176.1443196181000.16310.1443196200749@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ond?ej Chaloupka updated WFLY-5413:
-----------------------------------
    Affects Version/s: 10.0.0.CR1


> On IIOP migration default properties are not persisted
> ------------------------------------------------------
>
>                 Key: WFLY-5413
>                 URL: https://issues.jboss.org/browse/WFLY-5413
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Tomasz Adamski
>
> If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such  property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML.
> It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly.
> The example of such properties which do not persist because of its default values are
> * initializers: security="none"
> * security: client-supports="ServerAuth" server-supports="MutualAuth" 
> * security: client-requires="None" server-requires="None"
> * transport-config: detect-misordering="none"
> * as-context: auth-method="username_password" required="false"
> * sas-context caller-propagation="none"
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 11:54:00 2015
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 25 Sep 2015 11:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5365) Upgrade Narayana to
	5.0.7.Final
In-Reply-To: <JIRA.12585370.1442575756000@Atlassian.JIRA>
References: <JIRA.12585370.1442575756000@Atlassian.JIRA>
	<JIRA.12585370.1442575756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585370.1442575756000.16328.1443196440286@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson resolved WFLY-5365.
---------------------------------
    Resolution: Out of Date


Feel free to reopen if another 9.x release is scheduled

> Upgrade Narayana to 5.0.7.Final
> -------------------------------
>
>                 Key: WFLY-5365
>                 URL: https://issues.jboss.org/browse/WFLY-5365
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>    Affects Versions: 9.0.0.CR2
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 9.x.x TBD
>
>
> WFLY-5261 reports that the :reload operation on the server fails because the transaction subsystem does not stop correctly and fails to restart. We have created another release (5.0.7.Final) containing just the fix for https://issues.jboss.org/browse/JBTM-2514



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 12:04:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Fri, 25 Sep 2015 12:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5414) IIOP xsd schema does not
 contain default values for some of the attributes
In-Reply-To: <JIRA.12586183.1443197012000@Atlassian.JIRA>
References: <JIRA.12586183.1443197012000@Atlassian.JIRA>
	<JIRA.12586183.1443197012383@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586183.1443197012000.16354.1443197040264@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5414:
--------------------------------------

             Summary: IIOP xsd schema does not contain default values for some of the attributes
                 Key: WFLY-5414
                 URL: https://issues.jboss.org/browse/WFLY-5414
             Project: WildFly
          Issue Type: Bug
          Components: IIOP
            Reporter: Ond?ej Chaloupka
            Assignee: Tomasz Adamski


If checking the xsd of IIOP subsystem at {{jboss-as-iiop-openjdk_1_0.xsd}} there are some properties which behaves to have a default values (and such information could be found in listing of {{jboss-cli.sh}} by {{/subsystem=iiop-openjdk:read-resource-description()}} but defaults are not listed in xsd.

This is problem of types
* iorTransportConfigType
* iorASContextType
* iorSASContextType

I think that xsd of the iiop subsystem should contain the default values if exist.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 12:13:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Fri, 25 Sep 2015 12:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3330) Support
	enabled-cipher-suites="ALL"
In-Reply-To: <JIRA.12540344.1399643221000@Atlassian.JIRA>
References: <JIRA.12540344.1399643221000@Atlassian.JIRA>
	<JIRA.12540344.1399643221000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540344.1399643221000.16377.1443197580491@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFLY-3330:
------------------------------------
    Fix Version/s: 10.0.0.Final


> Support enabled-cipher-suites="ALL" 
> ------------------------------------
>
>                 Key: WFLY-3330
>                 URL: https://issues.jboss.org/browse/WFLY-3330
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.CR1
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.0.Final
>
>
> If I want to enable all ciphers format except MD5 I would have to specify a long list of all supported ciphers.
> Using the "ALL" keyword with a list of excluded elements this becomes easy to configure.
> The expected fopattern would be ALL:!ELT1:!ELT2
> Thus ALL:!MD5 would enable all supported ciphers except MD5.
> This is based on OpenSSL syntax for ciphers https://www.openssl.org/docs/apps/ciphers.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 12:13:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Fri, 25 Sep 2015 12:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3330) Support
	enabled-cipher-suites="ALL"
In-Reply-To: <JIRA.12540344.1399643221000@Atlassian.JIRA>
References: <JIRA.12540344.1399643221000@Atlassian.JIRA>
	<JIRA.12540344.1399643221000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540344.1399643221000.16383.1443197580602@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFLY-3330:
------------------------------------
    Priority: Blocker  (was: Major)


> Support enabled-cipher-suites="ALL" 
> ------------------------------------
>
>                 Key: WFLY-3330
>                 URL: https://issues.jboss.org/browse/WFLY-3330
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.CR1
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>
> If I want to enable all ciphers format except MD5 I would have to specify a long list of all supported ciphers.
> Using the "ALL" keyword with a list of excluded elements this becomes easy to configure.
> The expected fopattern would be ALL:!ELT1:!ELT2
> Thus ALL:!MD5 would enable all supported ciphers except MD5.
> This is based on OpenSSL syntax for ciphers https://www.openssl.org/docs/apps/ciphers.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 12:23:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 25 Sep 2015 12:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-928) ParserHelper can throw a
 IndexOutOfBoundsException when parsing a malformed drl
In-Reply-To: <JIRA.12586187.1443198174000@Atlassian.JIRA>
References: <JIRA.12586187.1443198174000@Atlassian.JIRA>
	<JIRA.12586187.1443198174241@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586187.1443198174000.16439.1443198180130@Atlassian.JIRA>

Mario Fusco created DROOLS-928:
----------------------------------

             Summary: ParserHelper can throw a IndexOutOfBoundsException when parsing a malformed drl
                 Key: DROOLS-928
                 URL: https://issues.jboss.org/browse/DROOLS-928
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


ParserHelper can throw a IndexOutOfBoundsException when parsing a malformed drl



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 12:25:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 25 Sep 2015 12:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-928) ParserHelper can throw a
 IndexOutOfBoundsException when parsing a malformed drl
In-Reply-To: <JIRA.12586187.1443198174000@Atlassian.JIRA>
References: <JIRA.12586187.1443198174000@Atlassian.JIRA>
	<JIRA.12586187.1443198174000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586187.1443198174000.16443.1443198300137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-928.
--------------------------------
    Fix Version/s: 6.4.x
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/6498da712

> ParserHelper can throw a IndexOutOfBoundsException when parsing a malformed drl
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-928
>                 URL: https://issues.jboss.org/browse/DROOLS-928
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.4.x
>
>
> ParserHelper can throw a IndexOutOfBoundsException when parsing a malformed drl



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 13:07:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 25 Sep 2015 13:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.16522.1443200820141@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112654#comment-13112654 ] 

Kabir Khan commented on WFCORE-994:
-----------------------------------

[~hbraun][~harald.pehl] Please take a look at my https://github.com/wildfly/wildfly-core/compare/wildfly:master...kabir:WFCORE-994?expand=1

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR6
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 13:47:00 2015
From: issues at jboss.org (Daniel Coughlin (JIRA))
Date: Fri, 25 Sep 2015 13:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9573) Broken link on
	developers.redhat.com
In-Reply-To: <JIRA.12586193.1443203199000@Atlassian.JIRA>
References: <JIRA.12586193.1443203199000@Atlassian.JIRA>
	<JIRA.12586193.1443203199589@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586193.1443203199000.16589.1443203220098@Atlassian.JIRA>

Daniel Coughlin created JBAS-9573:
-------------------------------------

             Summary: Broken link on developers.redhat.com
                 Key: JBAS-9573
                 URL: https://issues.jboss.org/browse/JBAS-9573
             Project: Application Server 3  4  5 and 6
          Issue Type: Feature Request
            Reporter: Daniel Coughlin


The following broken link is currently listed against this project on developers.redhat.com/projects.

https://jboss.org/jbossas/osgi

(<a class="image-link" href="https://jboss.org/jbossas/osgi"><img onerror="app.project.fallbackImage(this)" src="http://static.jboss.org/jbossas_osgi/images/jbossas_osgi_200x150.png" alt="JBoss OSGi"></a>)

If you maintain a project.properties file that you have told the RHD team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 14:18:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 25 Sep 2015 14:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1013) Make the ServerEnvironment
 UUID configurable via system property
In-Reply-To: <JIRA.12586195.1443205042000@Atlassian.JIRA>
References: <JIRA.12586195.1443205042000@Atlassian.JIRA>
	<JIRA.12586195.1443205042372@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586195.1443205042000.16611.1443205080070@Atlassian.JIRA>

Brian Stansberry created WFCORE-1013:
----------------------------------------

             Summary: Make the ServerEnvironment UUID configurable via system property
                 Key: WFCORE-1013
                 URL: https://issues.jboss.org/browse/WFCORE-1013
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR6


Allow users to provide the UUID exposed by the ServerEnvironment resource. The specific use case for this is to allow wildfly-swarm to pass in a consistent UUID across multiple starts of the process without relying on the persisted version of the id.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 14:26:00 2015
From: issues at jboss.org (Daniel Coughlin (JIRA))
Date: Fri, 25 Sep 2015 14:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9573) Broken link on
	developers.redhat.com
In-Reply-To: <JIRA.12586193.1443203199000@Atlassian.JIRA>
References: <JIRA.12586193.1443203199000@Atlassian.JIRA>
	<JIRA.12586193.1443203199000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586193.1443203199000.16629.1443205560163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBAS-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112669#comment-13112669 ] 

Daniel Coughlin commented on JBAS-9573:
---------------------------------------

We are currently ignoring the link on our link checker (https://github.com/redhat-developer/developers.redhat.com/blob/master/_config/blinkr.yaml).  Once the link is fixed, we'll need to remove the ignore from this in order to make sure that the link is valid.

> Broken link on developers.redhat.com
> ------------------------------------
>
>                 Key: JBAS-9573
>                 URL: https://issues.jboss.org/browse/JBAS-9573
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Feature Request
>            Reporter: Daniel Coughlin
>
> The following broken link is currently listed against this project on developers.redhat.com/projects.
> https://jboss.org/jbossas/osgi
> (<a class="image-link" href="https://jboss.org/jbossas/osgi"><img onerror="app.project.fallbackImage(this)" src="http://static.jboss.org/jbossas_osgi/images/jbossas_osgi_200x150.png" alt="JBoss OSGi"></a>)
> If you maintain a project.properties file that you have told the RHD team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 14:27:00 2015
From: issues at jboss.org (Daniel Coughlin (JIRA))
Date: Fri, 25 Sep 2015 14:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1293) Broken Links on JBoss.org &
 developers.redhat.com
In-Reply-To: <JIRA.12585550.1442851093000@Atlassian.JIRA>
References: <JIRA.12585550.1442851093000@Atlassian.JIRA>
	<JIRA.12585550.1442851093000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585550.1442851093000.16633.1443205620176@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112671#comment-13112671 ] 

Daniel Coughlin commented on JBJCA-1293:
----------------------------------------

We are currently ignoring the link on our link checker (https://github.com/redhat-developer/developers.redhat.com/blob/master/_config/blinkr.yaml).  Once the link is fixed, we'll need to remove the ignore from this in order to make sure that the link is valid.

> Broken Links on JBoss.org & developers.redhat.com
> -------------------------------------------------
>
>                 Key: JBJCA-1293
>                 URL: https://issues.jboss.org/browse/JBJCA-1293
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Daniel Coughlin
>            Assignee: Jesper Pedersen
>
> The following broken link is currently listed against this project on developers.redhat.com/projects.
> http://fisheye.jboss.com/browse/JBossAS/projects/jboss-jca/trunk/
> If you maintain a project.properties file that you have told the RHD team about, then you just need to fix it in there and the change will be reflected on the site. Otherwise, you need to update the data on this project's Magnolia page.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 14:27:00 2015
From: issues at jboss.org (Elizabeth K. Joseph (JIRA))
Date: Fri, 25 Sep 2015 14:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5415) wildfly-init-debian.sh
 overwrites previous log
In-Reply-To: <JIRA.12586197.1443205612000@Atlassian.JIRA>
References: <JIRA.12586197.1443205612000@Atlassian.JIRA>
	<JIRA.12586197.1443205612456@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586197.1443205612000.16638.1443205620257@Atlassian.JIRA>

Elizabeth K. Joseph created WFLY-5415:
-----------------------------------------

             Summary: wildfly-init-debian.sh overwrites previous log
                 Key: WFLY-5415
                 URL: https://issues.jboss.org/browse/WFLY-5415
             Project: WildFly
          Issue Type: Bug
          Components: Scripts
    Affects Versions: 9.0.1.Final
         Environment: Wildfly 9.0.1 Final on Ubuntu 14.04 LTS running the Zanata (zanata.org) translations platform.
            Reporter: Elizabeth K. Joseph
            Assignee: Tomaz Cerar
            Priority: Minor


We had to restart Wildfly on our Ubuntu 14.04 LTS server due to some issues with the application on top of it, and during the restart the init script wiped out our old logs and replaced them with the new logs, leaving us with none of the debugging information needed to track down our problem.

It looks like this line is to blame in bin/init.d/wildfly-init-debian.sh:

cat /dev/null > "$JBOSS_CONSOLE_LOG"

Currently using wildfly-9.0.1.Final.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 15:24:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 25 Sep 2015 15:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1013) Make the ServerEnvironment
 UUID configurable via system property
In-Reply-To: <JIRA.12586195.1443205042000@Atlassian.JIRA>
References: <JIRA.12586195.1443205042000@Atlassian.JIRA>
	<JIRA.12586195.1443205042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586195.1443205042000.16708.1443209040102@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1013:
-------------------------------------
    Description: # Allow users to provide the UUID exposed by the ServerEnvironment and HostControllerEnvironment objects, and to end users via the root server and host management resources. The specific use case for this is to allow wildfly-swarm to pass in a consistent UUID across multiple starts of the process without relying on the persisted version of the id.  (was: Allow users to provide the UUID exposed by the ServerEnvironment resource. The specific use case for this is to allow wildfly-swarm to pass in a consistent UUID across multiple starts of the process without relying on the persisted version of the id.)


> Make the ServerEnvironment UUID configurable via system property
> ----------------------------------------------------------------
>
>                 Key: WFCORE-1013
>                 URL: https://issues.jboss.org/browse/WFCORE-1013
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> # Allow users to provide the UUID exposed by the ServerEnvironment and HostControllerEnvironment objects, and to end users via the root server and host management resources. The specific use case for this is to allow wildfly-swarm to pass in a consistent UUID across multiple starts of the process without relying on the persisted version of the id.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:00:00 2015
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 25 Sep 2015 16:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4465) Update PicketLink modules for
	Undertow.
In-Reply-To: <JIRA.12566938.1427325718000@Atlassian.JIRA>
References: <JIRA.12566938.1427325718000@Atlassian.JIRA>
	<JIRA.12566938.1427325718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566938.1427325718000.16734.1443211200085@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-4465:
-----------------------------
    Summary: Update PicketLink modules for Undertow.  (was: Change org.picketlink module to export services from org.picketlink.federation.bindings)


> Update PicketLink modules for Undertow.
> ---------------------------------------
>
>                 Key: WFLY-4465
>                 URL: https://issues.jboss.org/browse/WFLY-4465
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:07:00 2015
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 25 Sep 2015 16:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4465) Update PicketLink modules for
	Undertow
In-Reply-To: <JIRA.12566938.1427325718000@Atlassian.JIRA>
References: <JIRA.12566938.1427325718000@Atlassian.JIRA>
	<JIRA.12566938.1427325718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566938.1427325718000.16740.1443211620162@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-4465:
-----------------------------
    Summary: Update PicketLink modules for Undertow  (was: Update PicketLink modules for Undertow.)


> Update PicketLink modules for Undertow
> --------------------------------------
>
>                 Key: WFLY-4465
>                 URL: https://issues.jboss.org/browse/WFLY-4465
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:08:00 2015
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 25 Sep 2015 16:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4465) Update PicketLink modules for
	Undertow
In-Reply-To: <JIRA.12566938.1427325718000@Atlassian.JIRA>
References: <JIRA.12566938.1427325718000@Atlassian.JIRA>
	<JIRA.12566938.1427325718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566938.1427325718000.16754.1443211680277@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-4465:
-----------------------------
    Description: Update PicketLink modules in order to support currently capabilities provided in EAP 6 / JBossWeb.


> Update PicketLink modules for Undertow
> --------------------------------------
>
>                 Key: WFLY-4465
>                 URL: https://issues.jboss.org/browse/WFLY-4465
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 10.0.0.CR2
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> Update PicketLink modules in order to support currently capabilities provided in EAP 6 / JBossWeb.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:08:00 2015
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 25 Sep 2015 16:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4465) Update PicketLink modules for
	Undertow
In-Reply-To: <JIRA.12566938.1427325718000@Atlassian.JIRA>
References: <JIRA.12566938.1427325718000@Atlassian.JIRA>
	<JIRA.12566938.1427325718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566938.1427325718000.16756.1443211680307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-4465:
-----------------------------
    Affects Version/s: 10.0.0.CR2
                           (was: 9.0.0.Alpha1)


> Update PicketLink modules for Undertow
> --------------------------------------
>
>                 Key: WFLY-4465
>                 URL: https://issues.jboss.org/browse/WFLY-4465
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 10.0.0.CR2
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> Update PicketLink modules in order to support currently capabilities provided in EAP 6 / JBossWeb.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:20:00 2015
From: issues at jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 25 Sep 2015 16:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1014)
 DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model
 operation result outcome
In-Reply-To: <JIRA.12586207.1443212344000@Atlassian.JIRA>
References: <JIRA.12586207.1443212344000@Atlassian.JIRA>
	<JIRA.12586207.1443212344709@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586207.1443212344000.16853.1443212400783@Atlassian.JIRA>

Aaron Ogburn created WFCORE-1014:
------------------------------------

             Summary: DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome
                 Key: WFCORE-1014
                 URL: https://issues.jboss.org/browse/WFCORE-1014
             Project: WildFly Core
          Issue Type: Bug
    Affects Versions: 2.0.0.CR6
            Reporter: Aaron Ogburn


The deployment scanner doesn't properly consider the  result outcome of its read child operation during getDeploymentsStatus().  This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception.

The operation catches the exception and returns an empty result.  The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them.  The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:41:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 16:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1014)
 DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model
 operation result outcome
In-Reply-To: <JIRA.12586207.1443212344000@Atlassian.JIRA>
References: <JIRA.12586207.1443212344000@Atlassian.JIRA>
	<JIRA.12586207.1443212344000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586207.1443212344000.16942.1443213660250@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFCORE-1014:
--------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1266615
        Bugzilla Update: Perform


> DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1014
>                 URL: https://issues.jboss.org/browse/WFCORE-1014
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 2.0.0.CR6
>            Reporter: Aaron Ogburn
>
> The deployment scanner doesn't properly consider the  result outcome of its read child operation during getDeploymentsStatus().  This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception.
> The operation catches the exception and returns an empty result.  The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them.  The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:56:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 16:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1014)
 DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model
 operation result outcome
In-Reply-To: <JIRA.12586207.1443212344000@Atlassian.JIRA>
References: <JIRA.12586207.1443212344000@Atlassian.JIRA>
	<JIRA.12586207.1443212344000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586207.1443212344000.16976.1443214560077@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112688#comment-13112688 ] 

RH Bugzilla Integration commented on WFCORE-1014:
-------------------------------------------------

Aaron Ogburn <aogburn at redhat.com> changed the Status of [bug 1266615|https://bugzilla.redhat.com/show_bug.cgi?id=1266615] from NEW to ASSIGNED

> DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1014
>                 URL: https://issues.jboss.org/browse/WFCORE-1014
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 2.0.0.CR6
>            Reporter: Aaron Ogburn
>
> The deployment scanner doesn't properly consider the  result outcome of its read child operation during getDeploymentsStatus().  This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception.
> The operation catches the exception and returns an empty result.  The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them.  The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 16:58:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 25 Sep 2015 16:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-994) Inconsistent
 :rrd(access-control) response when querying host resources
In-Reply-To: <JIRA.12585529.1442844068000@Atlassian.JIRA>
References: <JIRA.12585529.1442844068000@Atlassian.JIRA>
	<JIRA.12585529.1442844068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585529.1442844068000.16981.1443214680217@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112689#comment-13112689 ] 

Kabir Khan commented on WFCORE-994:
-----------------------------------

I created https://github.com/wildfly/wildfly-core/pull/1122

> Inconsistent :rrd(access-control) response when querying host resources
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-994
>                 URL: https://issues.jboss.org/browse/WFCORE-994
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 2.0.0.CR6
>
>
> {noformat}
> [domain at localhost:9990 /] /host=*:read-resource-description(access-control=trim-descriptions){roles=Administrator}
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "address" => [("host" => "macbook-pro.fritz.box")],
>             "outcome" => "success",
>             "result" => {
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {}
>                     },
>                     "exceptions" => {}
>                 },
>                 "description" => undefined
>             }
>         },
>         {
>             "address" => [("host" => "master")],
>             "outcome" => "success",
>             "result" => {
>                 "description" => undefined,
>                 "attributes" => undefined,
>                 "operations" => undefined,
>                 "notifications" => undefined,
>                 "children" => {
>                     "core-service" => {"model-description" => undefined},
>                     "jvm" => {"model-description" => undefined},
>                     "socket-binding-group" => {"model-description" => undefined},
>                     "path" => {"model-description" => undefined},
>                     "server" => {"model-description" => undefined},
>                     "subsystem" => {"model-description" => undefined},
>                     "server-config" => {"model-description" => undefined},
>                     "interface" => {"model-description" => undefined},
>                     "system-property" => {"model-description" => undefined},
>                     "extension" => {"model-description" => undefined}
>                 },
>                 "access-control" => {
>                     "default" => {
>                         "read" => true,
>                         "write" => true,
>                         "attributes" => {
>                             "directory-grouping" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-controller" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "domain-organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "host-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-major-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-micro-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "management-minor-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "master" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "namespaces" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "organization" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-name" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "product-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-codename" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "release-version" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "running-mode" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "schema-locations" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "server-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "suspend-state" => {
>                                 "read" => true,
>                                 "write" => true
>                             },
>                             "uuid" => {
>                                 "read" => true,
>                                 "write" => true
>                             }
>                         }
>                     },
>                     "exceptions" => {}
>                 }
>             }
>         }
>     ]
> }
> [domain at localhost:9990 /] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 17:02:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 17:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1014)
 DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model
 operation result outcome
In-Reply-To: <JIRA.12586207.1443212344000@Atlassian.JIRA>
References: <JIRA.12586207.1443212344000@Atlassian.JIRA>
	<JIRA.12586207.1443212344000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586207.1443212344000.16985.1443214920114@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112690#comment-13112690 ] 

RH Bugzilla Integration commented on WFCORE-1014:
-------------------------------------------------

Aaron Ogburn <aogburn at redhat.com> changed the Status of [bug 1266615|https://bugzilla.redhat.com/show_bug.cgi?id=1266615] from ASSIGNED to POST

> DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1014
>                 URL: https://issues.jboss.org/browse/WFCORE-1014
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 2.0.0.CR6
>            Reporter: Aaron Ogburn
>
> The deployment scanner doesn't properly consider the  result outcome of its read child operation during getDeploymentsStatus().  This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception.
> The operation catches the exception and returns an empty result.  The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them.  The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 19:16:01 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 25 Sep 2015 19:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5415) wildfly-init-debian.sh
 overwrites previous log
In-Reply-To: <JIRA.12586197.1443205612000@Atlassian.JIRA>
References: <JIRA.12586197.1443205612000@Atlassian.JIRA>
	<JIRA.12586197.1443205612000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586197.1443205612000.17278.1443222961751@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112701#comment-13112701 ] 

Tomaz Cerar commented on WFLY-5415:
-----------------------------------

you should be using server.log not console.log for everything that server logs.
console is primarily useful for development but can cause severe performance hit when used in production.

> wildfly-init-debian.sh overwrites previous log
> ----------------------------------------------
>
>                 Key: WFLY-5415
>                 URL: https://issues.jboss.org/browse/WFLY-5415
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 9.0.1.Final
>         Environment: Wildfly 9.0.1 Final on Ubuntu 14.04 LTS running the Zanata (zanata.org) translations platform.
>            Reporter: Elizabeth K. Joseph
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> We had to restart Wildfly on our Ubuntu 14.04 LTS server due to some issues with the application on top of it, and during the restart the init script wiped out our old logs and replaced them with the new logs, leaving us with none of the debugging information needed to track down our problem.
> It looks like this line is to blame in bin/init.d/wildfly-init-debian.sh:
> cat /dev/null > "$JBOSS_CONSOLE_LOG"
> Currently using wildfly-9.0.1.Final.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 19:21:01 2015
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Fri, 25 Sep 2015 19:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5416) Unhandled exceptions from
 custom JASPI modules should cause the HTTP status code to be set as an
 error (500, 400, etc)
In-Reply-To: <JIRA.12584738.1442003550000@Atlassian.JIRA>
References: <JIRA.12584738.1442003550000@Atlassian.JIRA>
	<JIRA.12584738.1442003550000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584738.1442003550000.17284.1443223261339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Spyrko-?mietanko moved UNDERTOW-540 to WFLY-5416:
---------------------------------------------------------

        Project: WildFly  (was: Undertow)
            Key: WFLY-5416  (was: UNDERTOW-540)
    Component/s: Web (Undertow)
                     (was: Security)


> Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc)
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5416
>                 URL: https://issues.jboss.org/browse/WFLY-5416
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Derek Horton
>            Assignee: Stuart Douglas
>
> If a custom JASPI auth module throws an exception, Wildfly/Undertow (the JASPI authenticator) ignores it and returns a 200.  The web page that was requested does not get displayed.  A blank page and a HTTP 200 are returned.
> Should a 40x or a 500 be returned instead?  Or is it the responsibility of the custom JASPI auth module to set the status correctly?
> It seems like the container would need to be careful and not overwrite a status code that the JASPI module had explicitly set.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Sep 25 19:26:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Sep 2015 19:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5416) Unhandled exceptions from
 custom JASPI modules should cause the HTTP status code to be set as an
 error (500, 400, etc)
In-Reply-To: <JIRA.12584738.1442003550000@Atlassian.JIRA>
References: <JIRA.12584738.1442003550000@Atlassian.JIRA>
	<JIRA.12584738.1442003550000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584738.1442003550000.17290.1443223560212@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-5416:
------------------------------------------
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=1262482)
        Bugzilla Update:   (was: Perform)


> Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc)
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5416
>                 URL: https://issues.jboss.org/browse/WFLY-5416
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Derek Horton
>            Assignee: Stuart Douglas
>
> If a custom JASPI auth module throws an exception, Wildfly/Undertow (the JASPI authenticator) ignores it and returns a 200.  The web page that was requested does not get displayed.  A blank page and a HTTP 200 are returned.
> Should a 40x or a 500 be returned instead?  Or is it the responsibility of the custom JASPI auth module to set the status correctly?
> It seems like the container would need to be careful and not overwrite a status code that the JASPI module had explicitly set.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 19:41:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Fri, 25 Sep 2015 19:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5417) jconsole EAP tab not loading
 when using remote
In-Reply-To: <JIRA.12586230.1443224451000@Atlassian.JIRA>
References: <JIRA.12586230.1443224451000@Atlassian.JIRA>
	<JIRA.12586230.1443224451334@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586230.1443224451000.17297.1443224460310@Atlassian.JIRA>

Brad Maxwell created WFLY-5417:
----------------------------------

             Summary: jconsole EAP tab not loading when using remote
                 Key: WFLY-5417
                 URL: https://issues.jboss.org/browse/WFLY-5417
             Project: WildFly
          Issue Type: Feature Request
          Components: CLI
            Reporter: Brad Maxwell
            Assignee: Alexey Loubyansky


Issue introduced with WFLY-1548, the dialog added with WFLY-1548 is to get a connection with jconsole local process connection is used to establish a connection to the management api.  This bug is because when using remote, the init(...) is not being called with the existing CommandContext



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 19:42:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Fri, 25 Sep 2015 19:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1015) jconsole EAP tab not
 loading when using remote
In-Reply-To: <JIRA.12586230.1443224451000@Atlassian.JIRA>
References: <JIRA.12586230.1443224451000@Atlassian.JIRA>
	<JIRA.12586230.1443224451000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586230.1443224451000.17300.1443224520143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell moved WFLY-5417 to WFCORE-1015:
--------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-1015  (was: WFLY-5417)
     Issue Type: Bug  (was: Feature Request)
    Component/s: CLI
                     (was: CLI)


> jconsole EAP tab not loading when using remote
> ----------------------------------------------
>
>                 Key: WFCORE-1015
>                 URL: https://issues.jboss.org/browse/WFCORE-1015
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Brad Maxwell
>            Assignee: Alexey Loubyansky
>
> Issue introduced with WFLY-1548, the dialog added with WFLY-1548 is to get a connection with jconsole local process connection is used to establish a connection to the management api.  This bug is because when using remote, the init(...) is not being called with the existing CommandContext



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 19:52:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Fri, 25 Sep 2015 19:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1015) jconsole EAP tab not
 loading when using remote
In-Reply-To: <JIRA.12586230.1443224451000@Atlassian.JIRA>
References: <JIRA.12586230.1443224451000@Atlassian.JIRA>
	<JIRA.12586230.1443224451000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586230.1443224451000.17303.1443225120106@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell reassigned WFCORE-1015:
------------------------------------

    Assignee: Brad Maxwell  (was: Alexey Loubyansky)


> jconsole EAP tab not loading when using remote
> ----------------------------------------------
>
>                 Key: WFCORE-1015
>                 URL: https://issues.jboss.org/browse/WFCORE-1015
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Issue introduced with WFLY-1548, the dialog added with WFLY-1548 is to get a connection with jconsole local process connection is used to establish a connection to the management api.  This bug is because when using remote, the init(...) is not being called with the existing CommandContext



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 19:53:00 2015
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Fri, 25 Sep 2015 19:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1015) jconsole Wildfly CLI tab
 not loading when using remote
In-Reply-To: <JIRA.12586230.1443224451000@Atlassian.JIRA>
References: <JIRA.12586230.1443224451000@Atlassian.JIRA>
	<JIRA.12586230.1443224451000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586230.1443224451000.17305.1443225180059@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFCORE-1015:
---------------------------------
    Summary: jconsole Wildfly CLI tab not loading when using remote  (was: jconsole EAP tab not loading when using remote)


> jconsole Wildfly CLI tab not loading when using remote
> ------------------------------------------------------
>
>                 Key: WFCORE-1015
>                 URL: https://issues.jboss.org/browse/WFCORE-1015
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Issue introduced with WFLY-1548, the dialog added with WFLY-1548 is to get a connection with jconsole local process connection is used to establish a connection to the management api.  This bug is because when using remote, the init(...) is not being called with the existing CommandContext



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 21:13:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 25 Sep 2015 21:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-998) Error executing composite op
 in domain with two hosts
In-Reply-To: <JIRA.12585669.1442932675000@Atlassian.JIRA>
References: <JIRA.12585669.1442932675000@Atlassian.JIRA>
	<JIRA.12585669.1442932675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585669.1442932675000.17316.1443229980261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-998:
------------------------------------
    Fix Version/s: 2.0.0.CR6
                       (was: 2.0.0.CR7)


> Error executing composite op in domain with two hosts
> -----------------------------------------------------
>
>                 Key: WFCORE-998
>                 URL: https://issues.jboss.org/browse/WFCORE-998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> {noformat}
>  Tue Sep 22 16:35:42 GMT+200 2015
> Failed to create security context for host=macbook-pro.fritz.box/server=server-four
> Unexpected HTTP response: 500
> Request
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [{
>         "address" => [
>             ("host" => "macbook-pro.fritz.box"),
>             ("server" => "server-four")
>         ],
>         "operation" => "read-resource-description",
>         "operations" => true,
>         "access-control" => "combined-descriptions",
>         "include-aliases" => true
>     }]
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => {"step-1" => undefined},
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]"}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"macbook-pro.fritz.box" => {"server-four" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0031: No operation named 'composite' exists at address [
>     (\"host\" => \"macbook-pro.fritz.box\"),
>     (\"server\" => \"server-four\")
> ]",
>         "rolled-back" => true
>     }}}}}}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Sep 25 22:13:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 25 Sep 2015 22:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1014)
 DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model
 operation result outcome
In-Reply-To: <JIRA.12586207.1443212344000@Atlassian.JIRA>
References: <JIRA.12586207.1443212344000@Atlassian.JIRA>
	<JIRA.12586207.1443212344000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586207.1443212344000.17331.1443233580187@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1014:
----------------------------------------

    Fix Version/s: 2.0.0.CR6
         Assignee: Aaron Ogburn
       Resolution: Done


> DefaultDeploymentOperations.getDeploymentsStatus doesn't consider model operation result outcome
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1014
>                 URL: https://issues.jboss.org/browse/WFCORE-1014
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 2.0.0.CR6
>            Reporter: Aaron Ogburn
>            Assignee: Aaron Ogburn
>             Fix For: 2.0.0.CR6
>
>
> The deployment scanner doesn't properly consider the  result outcome of its read child operation during getDeploymentsStatus().  This has bad consequences if the operation fails, for instance due to an OOME or possibly some other unexpected exception.
> The operation catches the exception and returns an empty result.  The deployment scanner misinterprets that empty result to mean there are no applications deployed and sets .undeployed marker files for all of them.  The deployment scanner should confirm if the operation was a success or not so we can avoid potential side effects of undeployed applications from an OOME.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Sep 27 17:36:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 27 Sep 2015 17:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1016) NPE or AssertionError if op
 is cancelled on slave between sending prepare and receiving commit/rollback
In-Reply-To: <JIRA.12586249.1443389718000@Atlassian.JIRA>
References: <JIRA.12586249.1443389718000@Atlassian.JIRA>
	<JIRA.12586249.1443389718426@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586249.1443389718000.17575.1443389760080@Atlassian.JIRA>

Brian Stansberry created WFCORE-1016:
----------------------------------------

             Summary: NPE or AssertionError if op is cancelled on slave between sending prepare and receiving commit/rollback
                 Key: WFCORE-1016
                 URL: https://issues.jboss.org/browse/WFCORE-1016
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.CR5
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR6


OperationCancellationTestCase showed this failure:

{code}
2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) block requested by testSlaveBlockCompletionCancelSlave for slave/undefined(COMMIT)
2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) will block at COMMIT for 20000
2015-09-23 06:43:40,164 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 71) WFLYCTL0352: Cancelling operation 'block' with id '1900489784' running on thread 'Host Controller Service Threads - 82'
2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) Exception in thread "Host Controller Service Threads - 82" java.lang.AssertionError
2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.completed(TransactionalProtocolOperationHandler.java:475)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at javax.security.auth.Subject.doAs(Subject.java:360)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.lang.Thread.run(Thread.java:745)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}

What happens here is the slave HC executing the 'block' op has sent a prepare message to the master, and then when the commit has not come back yet the test driver triggers a cancel on the slave. At this point the thread running the 'block' op returns and tries to send the final result to the master. But it fails because the prepare logic has nulled out the requestContext field, and the commit message has not arrived yet to restore a new one.

If assertions weren't enabled, the result would be an NPE when the null requestContext is used.

I don't see any reason for null out the requestContext.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 04:45:00 2015
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 28 Sep 2015 04:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5069) Missing service to represent
 the TransactionListenerRegistry
In-Reply-To: <JIRA.12580609.1438940968000@Atlassian.JIRA>
References: <JIRA.12580609.1438940968000@Atlassian.JIRA>
	<JIRA.12580609.1438940968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580609.1438940968000.17791.1443429900264@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated WFLY-5069:
-----------------------------------
    Priority: Minor  (was: Major)


> Missing service to represent the TransactionListenerRegistry
> ------------------------------------------------------------
>
>                 Key: WFLY-5069
>                 URL: https://issues.jboss.org/browse/WFLY-5069
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Minor
>
> JBTM-2343 added an observer SPI for tracking transaction state association changes for use by the JPA subsystem. This needs to be available as a wildfly service for consumption by other subsystems (currently JPA casts the TM to get hold of the TransactionListenerRegistry).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 05:09:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 28 Sep 2015 05:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5407) ActiveMQ Artemis 1.1.0 in
 Wildlfy differs from upstream tag 1.1.0
In-Reply-To: <JIRA.12586094.1443167411000@Atlassian.JIRA>
References: <JIRA.12586094.1443167411000@Atlassian.JIRA>
	<JIRA.12586094.1443167411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586094.1443167411000.17808.1443431340244@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-5407.
-------------------------------
    Fix Version/s: 10.0.0.CR2
       Resolution: Done


WildFly 10CR1 was released with Artemis 1.1.0-wildfly-6[1], created from a fork of Apache Artemis, because at that time, there were no available release of Artemis 1.1.0.

Since then, Artemis 1.1.0 has been released by Apache and this version is included in WildFly 10CR2

[1] https://github.com/wildfly/activemq-artemis

> ActiveMQ Artemis 1.1.0 in Wildlfy differs from upstream tag 1.1.0
> -----------------------------------------------------------------
>
>                 Key: WFLY-5407
>                 URL: https://issues.jboss.org/browse/WFLY-5407
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Martin Styk
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR2
>
>
> There are differences betweeen ActiveMQ Artemis tag 1.1.0 included in Wildlfy and Artemis tag 1.1.0 from apache/activemq-artemis Github repo.
> For example
> class org.apache.activemq.artemis.ra.ConnectionFactoryProperties in Artemis 1.1.0 included in Wildlfy doesn`t contain methods 
> {code:java}
> boolean equals(java.lang.Object)
> int hashCode()
> {code}
> class org.apache.activemq.artemis.ra.ActiveMQResourceAdapter  in Artemis 1.1.0 included in Wildlfy doesn`t contain methods 
> {code:java}
> void closeConnectionFactory(org.apache.activemq.artemis.ra.ConnectionFactoryProperties)
> {code}
> doesn`t contain field
> {code:java}
> java.util.Map knownConnectionFactories
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 05:09:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 28 Sep 2015 05:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5407) ActiveMQ Artemis 1.1.0 in
 Wildlfy differs from upstream tag 1.1.0
In-Reply-To: <JIRA.12586094.1443167411000@Atlassian.JIRA>
References: <JIRA.12586094.1443167411000@Atlassian.JIRA>
	<JIRA.12586094.1443167411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586094.1443167411000.17811.1443431340403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5407:
------------------------------
    Affects Version/s: 10.0.0.CR1


> ActiveMQ Artemis 1.1.0 in Wildlfy differs from upstream tag 1.1.0
> -----------------------------------------------------------------
>
>                 Key: WFLY-5407
>                 URL: https://issues.jboss.org/browse/WFLY-5407
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Martin Styk
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR2
>
>
> There are differences betweeen ActiveMQ Artemis tag 1.1.0 included in Wildlfy and Artemis tag 1.1.0 from apache/activemq-artemis Github repo.
> For example
> class org.apache.activemq.artemis.ra.ConnectionFactoryProperties in Artemis 1.1.0 included in Wildlfy doesn`t contain methods 
> {code:java}
> boolean equals(java.lang.Object)
> int hashCode()
> {code}
> class org.apache.activemq.artemis.ra.ActiveMQResourceAdapter  in Artemis 1.1.0 included in Wildlfy doesn`t contain methods 
> {code:java}
> void closeConnectionFactory(org.apache.activemq.artemis.ra.ConnectionFactoryProperties)
> {code}
> doesn`t contain field
> {code:java}
> java.util.Map knownConnectionFactories
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 05:33:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 28 Sep 2015 05:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-922) Drools Loops with this CEP
	test
In-Reply-To: <JIRA.12585302.1442523468000@Atlassian.JIRA>
References: <JIRA.12585302.1442523468000@Atlassian.JIRA>
	<JIRA.12585302.1442523468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585302.1442523468000.17838.1443432780211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-922.
--------------------------------
    Resolution: Rejected


I believe the loop is the behaviour you should expect with that given rule set. The sequence of events there is:

* insertion of MyMessage( "ATrigger" )
* fireAllRules executes "Rule A Start" that inserts "A-StateGuard" and "A-StartTimer" 
* insertion of MyMessage( "BTrigger" )
* fireAllRules executes "Second State" that 
# inserts "RuleFlow ended" 
# triggers rule "CleanUp" that remove all the 3 Strings
# since there's no String "A-StartTimer" rule "Rule A Start" can be triggered again inserting "A-StateGuard" and "A-StartTimer" 
# the insertion of "A-StateGuard" also triggers again "Second State"

... that closes the loop that is executed until the timed rules remove "A-StartTimer". 

I think you could achieve what you wanted by NOT deleting the String "A-StateGuard" in the consequence of rule "CleanUp".

Please reopen this ticket if you think that I'm overlooking something.



> Drools Loops with this CEP test
> -------------------------------
>
>                 Key: DROOLS-922
>                 URL: https://issues.jboss.org/browse/DROOLS-922
>             Project: Drools
>          Issue Type: Bug
>            Reporter: David Weir
>            Assignee: Mario Fusco
>         Attachments: DroolsLoopingTest.java, MyMessage.java
>
>
> I want to emulate the workflow style rules using state guards. When I run the attached, it loops many times until the incoming event expires.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 06:57:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 28 Sep 2015 06:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-906) Kiescanner do not find
 updates in the KieContainer if the current RELEASE of a maven artifact
 change selecting an older version
In-Reply-To: <JIRA.12584204.1441700444000@Atlassian.JIRA>
References: <JIRA.12584204.1441700444000@Atlassian.JIRA>
	<JIRA.12584204.1441700444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584204.1441700444000.17923.1443437820207@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112791#comment-13112791 ] 

Geoffrey De Smet commented on DROOLS-906:
-----------------------------------------

Why did the metadata file change? Did you change it manually or did a process change it? What's the motivation / use cases to change the metadata file?

> Kiescanner do not find updates in the KieContainer if the current RELEASE of a maven artifact change selecting an older version
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-906
>                 URL: https://issues.jboss.org/browse/DROOLS-906
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>         Environment: Ear containing a startup bean, with the kiescanner loaded at postconstruct,
> deployed in Wildfly 8.2.0 
>            Reporter: Getano Piazzolla
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: drools, kie, maven
>
> When using the KieScanner as indicated in the guide, if the kContainer is initalized using a ReleaseIdImpl that idicate
> as version "RELEASE", the KieScanner do not find changes in the repository if we indicate as RELEASE a previous version of the repository.
> IN CODE:
> ReleaseIdImpl releaseId = new ReleaseIdImpl("blabla", "blabla", "RELEASE");
> KieServices ks = KieServices.Factory.get();
> kContainer = ks.newKieContainer(releaseId);
> kieScanner = ks.newKieScanner(kContainer);
> kieScanner.start(5000L);
> For example if we change the maven-metadata.xml/maven-metadata-local.xml 
> FROM
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.2</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> TO
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.1</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> The kieScanner do not find changes; I have to restart the AS to be able to load the correct RELEASE version.
> (The kieScanner behaves and updates correctly if I change the release version from 0.1 to 0.2 )



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 07:09:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 28 Sep 2015 07:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-906) Kiescanner do not find
 updates in the KieContainer if the current RELEASE of a maven artifact
 change selecting an older version
In-Reply-To: <JIRA.12584204.1441700444000@Atlassian.JIRA>
References: <JIRA.12584204.1441700444000@Atlassian.JIRA>
	<JIRA.12584204.1441700444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584204.1441700444000.17937.1443438540204@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-906.
--------------------------------
    Resolution: Rejected


If I'm getting this correctly, you're trying to control the version of the kjar used in production through the maven repository metadata. This is not what that metadata is build for at all. It can be "refreshed" (= deleted and regerenated) at any time. 

In case I'm misunderstanding your use case, please feel free to reopen this ticket and better clarify it.



> Kiescanner do not find updates in the KieContainer if the current RELEASE of a maven artifact change selecting an older version
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-906
>                 URL: https://issues.jboss.org/browse/DROOLS-906
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>         Environment: Ear containing a startup bean, with the kiescanner loaded at postconstruct,
> deployed in Wildfly 8.2.0 
>            Reporter: Getano Piazzolla
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: drools, kie, maven
>
> When using the KieScanner as indicated in the guide, if the kContainer is initalized using a ReleaseIdImpl that idicate
> as version "RELEASE", the KieScanner do not find changes in the repository if we indicate as RELEASE a previous version of the repository.
> IN CODE:
> ReleaseIdImpl releaseId = new ReleaseIdImpl("blabla", "blabla", "RELEASE");
> KieServices ks = KieServices.Factory.get();
> kContainer = ks.newKieContainer(releaseId);
> kieScanner = ks.newKieScanner(kContainer);
> kieScanner.start(5000L);
> For example if we change the maven-metadata.xml/maven-metadata-local.xml 
> FROM
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.2</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> TO
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.1</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> The kieScanner do not find changes; I have to restart the AS to be able to load the correct RELEASE version.
> (The kieScanner behaves and updates correctly if I change the release version from 0.1 to 0.2 )



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 07:11:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 28 Sep 2015 07:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-906) Kiescanner do not find
 updates in the KieContainer if the current RELEASE of a maven artifact
 change selecting an older version
In-Reply-To: <JIRA.12584204.1441700444000@Atlassian.JIRA>
References: <JIRA.12584204.1441700444000@Atlassian.JIRA>
	<JIRA.12584204.1441700444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584204.1441700444000.17940.1443438660324@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112795#comment-13112795 ] 

Geoffrey De Smet commented on DROOLS-906:
-----------------------------------------

Some train of thoughts:

- We delegate this functionality to aether. So if this issue is to be fixed, it should be fixed upstream.
- As far as I know Maven/Aether, it is illegal to manipulate the maven repository's metadata to control the version of (k)jars used by projects that the depend on the version RELEASE. The main reason for this is that the metadata can be refreshed (= deteted and regenerated) at any time. The metadata is just and index for searches (to reduce network usage when determining the latest release, etc).
- RELEASE is a calculated property. If 0.1 and 0.2 are released, it should always be "0.2", as defined by the maven api.
- To control the version of the (k)jars being used by projects in production, specify the specific kjar version in a configuration file of your end-user app and use kie-ci to load that specific version. If you need a more centralized approach, then put the configuration file somewhere centrally

> Kiescanner do not find updates in the KieContainer if the current RELEASE of a maven artifact change selecting an older version
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-906
>                 URL: https://issues.jboss.org/browse/DROOLS-906
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>         Environment: Ear containing a startup bean, with the kiescanner loaded at postconstruct,
> deployed in Wildfly 8.2.0 
>            Reporter: Getano Piazzolla
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: drools, kie, maven
>
> When using the KieScanner as indicated in the guide, if the kContainer is initalized using a ReleaseIdImpl that idicate
> as version "RELEASE", the KieScanner do not find changes in the repository if we indicate as RELEASE a previous version of the repository.
> IN CODE:
> ReleaseIdImpl releaseId = new ReleaseIdImpl("blabla", "blabla", "RELEASE");
> KieServices ks = KieServices.Factory.get();
> kContainer = ks.newKieContainer(releaseId);
> kieScanner = ks.newKieScanner(kContainer);
> kieScanner.start(5000L);
> For example if we change the maven-metadata.xml/maven-metadata-local.xml 
> FROM
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.2</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> TO
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.1</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> The kieScanner do not find changes; I have to restart the AS to be able to load the correct RELEASE version.
> (The kieScanner behaves and updates correctly if I change the release version from 0.1 to 0.2 )



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 07:12:00 2015
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 28 Sep 2015 07:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-906) Kiescanner do not find
 updates in the KieContainer if the current RELEASE of a maven artifact
 change selecting an older version
In-Reply-To: <JIRA.12584204.1441700444000@Atlassian.JIRA>
References: <JIRA.12584204.1441700444000@Atlassian.JIRA>
	<JIRA.12584204.1441700444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584204.1441700444000.17945.1443438720261@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112795#comment-13112795 ] 

Geoffrey De Smet edited comment on DROOLS-906 at 9/28/15 7:11 AM:
------------------------------------------------------------------

Some thoughts:

- We delegate this functionality to aether. So if this issue is to be fixed, it should be fixed upstream.
- As far as I know Maven/Aether, it is illegal to manipulate the maven repository's metadata to control the version of (k)jars used by projects that the depend on the version RELEASE. The main reason for this is that the metadata can be refreshed (= deteted and regenerated) at any time. The metadata is just an index for searches (to reduce network usage when determining the latest release, etc).
- RELEASE is a calculated property. If 0.1 and 0.2 are released, it should always be "0.2", as defined by the maven api.
- To control the version of the (k)jars being used by projects in production, specify the specific kjar version in a configuration file of your end-user app and use kie-ci to load that specific version. If you need a more centralized approach, then put the configuration file somewhere centrally


was (Author: ge0ffrey):
Some train of thoughts:

- We delegate this functionality to aether. So if this issue is to be fixed, it should be fixed upstream.
- As far as I know Maven/Aether, it is illegal to manipulate the maven repository's metadata to control the version of (k)jars used by projects that the depend on the version RELEASE. The main reason for this is that the metadata can be refreshed (= deteted and regenerated) at any time. The metadata is just and index for searches (to reduce network usage when determining the latest release, etc).
- RELEASE is a calculated property. If 0.1 and 0.2 are released, it should always be "0.2", as defined by the maven api.
- To control the version of the (k)jars being used by projects in production, specify the specific kjar version in a configuration file of your end-user app and use kie-ci to load that specific version. If you need a more centralized approach, then put the configuration file somewhere centrally

> Kiescanner do not find updates in the KieContainer if the current RELEASE of a maven artifact change selecting an older version
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-906
>                 URL: https://issues.jboss.org/browse/DROOLS-906
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Final
>         Environment: Ear containing a startup bean, with the kiescanner loaded at postconstruct,
> deployed in Wildfly 8.2.0 
>            Reporter: Getano Piazzolla
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: drools, kie, maven
>
> When using the KieScanner as indicated in the guide, if the kContainer is initalized using a ReleaseIdImpl that idicate
> as version "RELEASE", the KieScanner do not find changes in the repository if we indicate as RELEASE a previous version of the repository.
> IN CODE:
> ReleaseIdImpl releaseId = new ReleaseIdImpl("blabla", "blabla", "RELEASE");
> KieServices ks = KieServices.Factory.get();
> kContainer = ks.newKieContainer(releaseId);
> kieScanner = ks.newKieScanner(kContainer);
> kieScanner.start(5000L);
> For example if we change the maven-metadata.xml/maven-metadata-local.xml 
> FROM
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.2</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> TO
> <metadata>
>   <groupId>com.noemalife.dmcs.rules</groupId>
>   <artifactId>maven-validation-rules</artifactId>
>   <versioning>
>     <release>0.1</release>
>     <versions>
>       <version>0.1</version>
>       <version>0.2</version>
>     </versions>
>     <lastUpdated></lastUpdated>
>   </versioning>
> </metadata>
> The kieScanner do not find changes; I have to restart the AS to be able to load the correct RELEASE version.
> (The kieScanner behaves and updates correctly if I change the release version from 0.1 to 0.2 )



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 08:49:00 2015
From: issues at jboss.org (Tom Ross (JIRA))
Date: Mon, 28 Sep 2015 08:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery
 operations are missing from MDB deployment in domain mode
In-Reply-To: <JIRA.12586289.1443444537000@Atlassian.JIRA>
References: <JIRA.12586289.1443444537000@Atlassian.JIRA>
	<JIRA.12586289.1443444537145@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586289.1443444537000.18094.1443444540208@Atlassian.JIRA>

Tom Ross created WFLY-5418:
------------------------------

             Summary: start-delivery/stop-delivery operations are missing from MDB deployment in domain mode
                 Key: WFLY-5418
                 URL: https://issues.jboss.org/browse/WFLY-5418
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: JBoss AS7 7.2.0.Final
         Environment: JBoss EAP 6.4.3
            Reporter: Tom Ross
            Assignee: Jeff Mesnil


It is possible to start/stop delivery of messages to MDB in standalone mode using operations
start-delivery() and stop-delivery() on MDB deployment. 

Those operations are missing from MDB deployment in domain mode



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:29:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 09:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-277) TS: Integrate JUnitDiff
In-Reply-To: <JIRA.12460907.1331103224000@Atlassian.JIRA>
References: <JIRA.12460907.1331103224000@Atlassian.JIRA>
	<JIRA.12460907.1331103224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460907.1331103224000.18180.1443446940102@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-277:
----------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


> TS: Integrate JUnitDiff
> -----------------------
>
>                 Key: WFLY-277
>                 URL: https://issues.jboss.org/browse/WFLY-277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> Running with
> {code}
> -DjunitDiff='<path1>:<path2>:<path3>'
> {code}
> would create a comparison to given testsuite result sets (JUnit .xml and txt files).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:30:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-277) TS: Integrate JUnitDiff
In-Reply-To: <JIRA.12460907.1331103224000@Atlassian.JIRA>
References: <JIRA.12460907.1331103224000@Atlassian.JIRA>
	<JIRA.12460907.1331103224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460907.1331103224000.18186.1443447000501@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed WFLY-277.
---------------------------------
    Resolution: Won't Fix


I'm closing this as there is no activity on it.

> TS: Integrate JUnitDiff
> -----------------------
>
>                 Key: WFLY-277
>                 URL: https://issues.jboss.org/browse/WFLY-277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> Running with
> {code}
> -DjunitDiff='<path1>:<path2>:<path3>'
> {code}
> would create a comparison to given testsuite result sets (JUnit .xml and txt files).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:33:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3921) Support direct JMX mbeans as
	dependecies
In-Reply-To: <JIRA.12553872.1412175689000@Atlassian.JIRA>
References: <JIRA.12553872.1412175689000@Atlassian.JIRA>
	<JIRA.12553872.1412175689000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553872.1412175689000.18195.1443447180127@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3921:
-----------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


I'm unscheduling this because the initial attempt at it proved harder than we expected and I don't believe that at this point we know when (or how) to resolve it.

> Support direct JMX mbeans as dependecies
> ----------------------------------------
>
>                 Key: WFLY-3921
>                 URL: https://issues.jboss.org/browse/WFLY-3921
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMX
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>
> We should be able to depend on existing mbeans from jboss-service.xml.
> (e.g. mbeans registered directly from JMX API)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:37:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Sep 2015 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery
 operations are missing from MDB deployment in domain mode
In-Reply-To: <JIRA.12586289.1443444537000@Atlassian.JIRA>
References: <JIRA.12586289.1443444537000@Atlassian.JIRA>
	<JIRA.12586289.1443444537000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586289.1443444537000.18202.1443447420178@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-5418:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1266913
        Bugzilla Update: Perform


> start-delivery/stop-delivery operations are missing from MDB deployment in domain mode
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5418
>                 URL: https://issues.jboss.org/browse/WFLY-5418
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: JBoss AS7 7.2.0.Final
>         Environment: JBoss EAP 6.4.3
>            Reporter: Tom Ross
>            Assignee: Jeff Mesnil
>
> It is possible to start/stop delivery of messages to MDB in standalone mode using operations
> start-delivery() and stop-delivery() on MDB deployment. 
> Those operations are missing from MDB deployment in domain mode



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:47:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 28 Sep 2015 09:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1009) Treat intra-domain
 transactional ":reload" and ":shutdown" requests similarly to how we handle
 end user requests
In-Reply-To: <JIRA.12586028.1443117252000@Atlassian.JIRA>
References: <JIRA.12586028.1443117252000@Atlassian.JIRA>
	<JIRA.12586028.1443117252000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586028.1443117252000.18228.1443448020325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFCORE-1009:
-----------------------------------------

    Assignee: ehsavoie Hugonnet


> Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1009
>                 URL: https://issues.jboss.org/browse/WFCORE-1009
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>
> ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services. WFCORE-1008 proposes expanding this to the ":shutdown" operation as well.
> This JIRA proposes expanding this to the TransactionalProtocolOperationHandler used for intra-domain process requests as well.
> The implementation here would be slightly different in that the response to the prepared notification from the op would be unchanged. What would change would be the handling of the tx commit coming from the client. The tx commit message handling would send the response instead of waiting for the original op to complete.
> The client side state related to the status of the reloading/shutting down slave HC or server should be fine. A master HC's tracking of slaves is unaffected by proxying a reload or shutdown op; it monitors the master<->slave comm channel to track the slave. Same thing for an HC reloading a server. For the case where an HC is stopping a server by sending a ":shutdown" request, the response to the request puts the HC's view of the server's state into InternalState.PROCESS_STOPPING. This state is valid as soon as the HC commits the ":shutdown" request, so this JIRA is consistent with that handling.
> (Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:47:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 28 Sep 2015 09:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1008) Treat ":shutdown" requests
 similarly to ":reload" in the server-side operation handler
In-Reply-To: <JIRA.12586026.1443116399000@Atlassian.JIRA>
References: <JIRA.12586026.1443116399000@Atlassian.JIRA>
	<JIRA.12586026.1443116399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586026.1443116399000.18235.1443448020484@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFCORE-1008:
-----------------------------------------

    Assignee: ehsavoie Hugonnet


> Treat ":shutdown" requests similarly to ":reload" in the server-side operation handler
> --------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1008
>                 URL: https://issues.jboss.org/browse/WFCORE-1008
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>
> ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services.
> A ":shutdown" op has similar effects to a ":reload" so there is no reason to treat it differently.
> (Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.) 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:47:00 2015
From: issues at jboss.org (skarimir skarimir (JIRA))
Date: Mon, 28 Sep 2015 09:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5419) Deployed webservices in war
 do not show up in admin console
In-Reply-To: <JIRA.12586293.1443447971000@Atlassian.JIRA>
References: <JIRA.12586293.1443447971000@Atlassian.JIRA>
	<JIRA.12586293.1443447971397@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586293.1443447971000.18238.1443448020536@Atlassian.JIRA>

skarimir skarimir created WFLY-5419:
---------------------------------------

             Summary: Deployed webservices in war do not show up in admin console
                 Key: WFLY-5419
                 URL: https://issues.jboss.org/browse/WFLY-5419
             Project: WildFly
          Issue Type: Bug
          Components: Web Console, Web Services
    Affects Versions: 10.0.0.CR2, 9.0.1.Final
            Reporter: skarimir skarimir
            Assignee: Heiko Braun


Webservices deployed in a war do not show up in the Administration Console under runtime > subsystems > webservices. This works in wildfly 8 with the same war. You can reproduce this using the quickstart example https://github.com/wildfly/quickstart/tree/9.x/helloworld-ws



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:50:01 2015
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Mon, 28 Sep 2015 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.18258.1443448201567@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112840#comment-13112840 ] 

Stefano Maestri commented on WFLY-5020:
---------------------------------------

Hi,

I'm a bit puzzled by your module config. A correct deployment w/ module should have a module created in modules/system/layers/base directory w/ its jar and a module.xml definition. Then standalone config of datasource should looks like:

{code:java}
<datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
			<connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
			<driver>microsoft</driver>
			<security>
  				<user-name>username1</user-name>
  				<password>password1</password>
			</security>
		</datasource>
                <drivers>
                    <driver name="h2" module="com.h2database.h2">
                        <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
                    </driver>
		    <driver name="microsoft" module="com.microsoft.sql"></driver>
                </drivers>
{code}

Please note definition of driver in xml pointing the created module. I can't see anything of this in your module configuration.
Anyway I've configured and tried exactly the above configuration and it works w/o problem.
Looking again in the code I can see jdbc-store isn't designed to work w/ hot deployed driver (BTW it's not a best practice in general), I thought it was pointed out in documentation, but quite frankly I haven't found it. Maybe something to improve in documentation, but it's a different area and issue is solved even for sql server and any other database using module configuration. So I'm closing again this issue. Feel free to open a documentation improvement issue pointing this comment.

regards
S.

> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>         Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:50:01 2015
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Mon, 28 Sep 2015 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5020) Server fails to start with
 transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12579558.1438071993000@Atlassian.JIRA>
References: <JIRA.12579558.1438071993000@Atlassian.JIRA>
	<JIRA.12579558.1438071993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579558.1438071993000.18262.1443448201723@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri resolved WFLY-5020.
-----------------------------------
    Resolution: Done


> Server fails to start with transactions configured to be run with JDBCObject store
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5020
>                 URL: https://issues.jboss.org/browse/WFLY-5020
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Hayk Hovsepyan
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>         Attachments: server.log, server_module.log, standalone.xml, standalone_module.xml
>
>
> When you configure transactions subsystem for running with JDBCObject store, the app server fails to start because of a error below.
> Error message:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 60) WFLYCTL0013: 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.rarepository, service jboss.data-source.java:jboss/datasources/jdbc-store, service jboss.data-source.reference-factory.JDBCPool, service jboss.naming.context.java.jboss.datasources.jdbc-store]
> {code}
> Datasource configuration is:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCPool" enabled="true" use-java-context="true">
> <connection-url>jdbc:sqlserver://mssql2014server:1433;DatabaseName=database1</connection-url>
> <driver>sqljdbc4.jar</driver>
> <security>
>   <user-name>username1</user-name>
>   <password>password1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:51:00 2015
From: issues at jboss.org (The Alchemist (JIRA))
Date: Mon, 28 Sep 2015 09:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5420) jboss-javaee-7.0-wildfly POMs
 (and friends) need updating to Wildfly 10CR2
In-Reply-To: <JIRA.12586294.1443448204000@Atlassian.JIRA>
References: <JIRA.12586294.1443448204000@Atlassian.JIRA>
	<JIRA.12586294.1443448204370@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586294.1443448204000.18267.1443448260544@Atlassian.JIRA>

The Alchemist created WFLY-5420:
-----------------------------------

             Summary: jboss-javaee-7.0-wildfly POMs (and friends) need updating to Wildfly 10CR2
                 Key: WFLY-5420
                 URL: https://issues.jboss.org/browse/WFLY-5420
             Project: WildFly
          Issue Type: Feature Request
    Affects Versions: 10.0.0.CR2
            Reporter: The Alchemist
            Assignee: Jason Greene


http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22jboss-javaee-7.0-wildfly%22

10.0.0.Beta2  is the version of the latest POMs.  Perhaps someone just needs to do a {{mvn deploy}}?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:53:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 28 Sep 2015 09:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-958) Bump the model and schema
 version of the Remoting subsystem.
In-Reply-To: <JIRA.12584050.1441386078000@Atlassian.JIRA>
References: <JIRA.12584050.1441386078000@Atlassian.JIRA>
	<JIRA.12584050.1441386078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584050.1441386078000.18315.1443448380935@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-958:
------------------------------------
    Labels: affects_elytron  (was: )


> Bump the model and schema version of the Remoting subsystem.
> ------------------------------------------------------------
>
>                 Key: WFCORE-958
>                 URL: https://issues.jboss.org/browse/WFCORE-958
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 09:54:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 28 Sep 2015 09:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-958) Bump the model and schema
 version of the Remoting subsystem.
In-Reply-To: <JIRA.12584050.1441386078000@Atlassian.JIRA>
References: <JIRA.12584050.1441386078000@Atlassian.JIRA>
	<JIRA.12584050.1441386078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584050.1441386078000.18320.1443448440140@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112842#comment-13112842 ] 

Darran Lofthouse commented on WFCORE-958:
-----------------------------------------

Changes for this are in the following branch: -
  https://github.com/darranl/wildfly-core/tree/WFCORE-958

> Bump the model and schema version of the Remoting subsystem.
> ------------------------------------------------------------
>
>                 Key: WFCORE-958
>                 URL: https://issues.jboss.org/browse/WFCORE-958
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 10:07:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 10:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-751) Failed to initialize Aesh
 console while starting CLI on fresh Windows 2k8
In-Reply-To: <JIRA.12574354.1433853926000@Atlassian.JIRA>
References: <JIRA.12574354.1433853926000@Atlassian.JIRA>
	<JIRA.12574354.1433853926000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574354.1433853926000.18391.1443449220335@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112851#comment-13112851 ] 

Brian Stansberry commented on WFCORE-751:
-----------------------------------------

[~aloubyansky] Any news on this? The JBEAP version of this is marked as a blocker.

> Failed to initialize Aesh console while starting CLI on fresh Windows 2k8
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-751
>                 URL: https://issues.jboss.org/browse/WFCORE-751
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha4
>         Environment: Windows Server 2008 64bit Service Pack 2
> Oracle JDK 8_40 & 8_45
>            Reporter: Petr Kremensky
>            Assignee: Alexey Loubyansky
>
> Initializing interactive CLI session via jboss-cli.bat script fails during initializing of Aesh console. Non-interactive commands work.
> >jboss-cli.bat -c 
> fails
> >jboss-cli.bat -c "echo test"
> works
> Installing Microsoft Visual C++ 2008 Redistributable Package solves the problem
> We encountered a similar issue in the past with EAP installer jar:\\
> Bug 1190789 - Installer: Installation of EAP with installation script fails on Windows W2k8 servers



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 10:54:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 28 Sep 2015 10:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5401) Bump the schema and model
 version of the Undertow subsystem
In-Reply-To: <JIRA.12585958.1443098748000@Atlassian.JIRA>
References: <JIRA.12585958.1443098748000@Atlassian.JIRA>
	<JIRA.12585958.1443098748000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585958.1443098748000.18733.1443452040103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-5401:
-----------------------------------
    Labels: affects_elytron  (was: )


> Bump the schema and model version of the Undertow subsystem
> -----------------------------------------------------------
>
>                 Key: WFLY-5401
>                 URL: https://issues.jboss.org/browse/WFLY-5401
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 11:03:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 11:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3612) Implement missing
 transformers for new bean validation subsystem
In-Reply-To: <JIRA.12546142.1405043868000@Atlassian.JIRA>
References: <JIRA.12546142.1405043868000@Atlassian.JIRA>
	<JIRA.12546142.1405043868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546142.1405043868000.18788.1443452580248@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3612:
-----------------------------------
    Description: 
The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFCORE-291 is done.

>From my comment on the PR for the WFLY-3551 work:

There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.

If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But

1) it's a corner case
2) it may not matter anyway in terms of behavior of an app
3) the transformer logic we have doesn't allow us to do anything about it anyway.


Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.

  was:
The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFLY-3563 is done.

>From my comment on the PR for the WFLY-3551 work:

There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.

If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But

1) it's a corner case
2) it may not matter anyway in terms of behavior of an app
3) the transformer logic we have doesn't allow us to do anything about it anyway.


Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.



> Implement missing transformers for new bean validation subsystem
> ----------------------------------------------------------------
>
>                 Key: WFLY-3612
>                 URL: https://issues.jboss.org/browse/WFLY-3612
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, EE
>            Reporter: Brian Stansberry
>            Assignee: Eduardo Martins
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>
> The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFCORE-291 is done.
> From my comment on the PR for the WFLY-3551 work:
> There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.
> If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But
> 1) it's a corner case
> 2) it may not matter anyway in terms of behavior of an app
> 3) the transformer logic we have doesn't allow us to do anything about it anyway.
> Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 11:04:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 11:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3612) Implement missing
 transformers for new bean validation subsystem
In-Reply-To: <JIRA.12546142.1405043868000@Atlassian.JIRA>
References: <JIRA.12546142.1405043868000@Atlassian.JIRA>
	<JIRA.12546142.1405043868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546142.1405043868000.18795.1443452640251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3612:
-----------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


Unscheduling as the depended-upon WFCORE-291 is unscheduled.

> Implement missing transformers for new bean validation subsystem
> ----------------------------------------------------------------
>
>                 Key: WFLY-3612
>                 URL: https://issues.jboss.org/browse/WFLY-3612
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, EE
>            Reporter: Brian Stansberry
>            Assignee: Eduardo Martins
>            Priority: Blocker
>
> The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFCORE-291 is done.
> From my comment on the PR for the WFLY-3551 work:
> There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.
> If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But
> 1) it's a corner case
> 2) it may not matter anyway in terms of behavior of an app
> 3) the transformer logic we have doesn't allow us to do anything about it anyway.
> Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 11:22:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 28 Sep 2015 11:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-948) Multiprocess wildcard
 read-resource-description does not work
In-Reply-To: <JIRA.12583632.1441244592000@Atlassian.JIRA>
References: <JIRA.12583632.1441244592000@Atlassian.JIRA>
	<JIRA.12583632.1441244592000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583632.1441244592000.18861.1443453720312@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFCORE-948:
---------------------------------

    Assignee: Kabir Khan


> Multiprocess wildcard read-resource-description does not work
> -------------------------------------------------------------
>
>                 Key: WFCORE-948
>                 URL: https://issues.jboss.org/browse/WFCORE-948
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Beta5
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>
> {code}
> [domain at localhost:9990 /] /host=master/server=*/interface=public:read-resource-description
> {
>     "outcome" => "failed",
>     "result" => [
>         {
>             "address" => [
>                 ("host" => "master"),
>                 ("server" => "*"),
>                 ("interface" => "public")
>             ],
>             "outcome" => "failed",
>             "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>             "rolled-back" => true
>         },
>         {
>             "address" => [
>                 ("host" => "master"),
>                 ("server" => "server-one"),
>                 ("interface" => "public")
>             ],
>             "outcome" => "failed",
>             "result" => undefined,
>             "rolled-back" => true
>         },
>         {
>             "address" => [
>                 ("host" => "master"),
>                 ("server" => "server-two"),
>                 ("interface" => "public")
>             ],
>             "outcome" => "failed",
>             "result" => undefined,
>             "rolled-back" => true
>         }
>     ],
>     "failure-description" => "WFLYCTL0285: Operation read-resource-description invoked against multiple target addresses failed at address [
>     (\"host\" => \"master\"),
>     (\"server\" => \"*\"),
>     (\"interface\" => \"public\")
> ] with failure description WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> {code}
> In the HC log:
> {code}
> [Host Controller] 20:37:28,277 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("read-resource-description") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server" => "*"),
> [Host Controller]     ("interface" => "public")
> [Host Controller] ]): java.lang.NullPointerException
> [Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.getResourceRegistrationCheckForAlias(ReadResourceDescriptionHandler.java:391)
> [Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecuteInternal(ReadResourceDescriptionHandler.java:189)
> [Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecute(ReadResourceDescriptionHandler.java:161)
> [Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.access$300(ReadResourceDescriptionHandler.java:97)
> [Host Controller] 	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$2.execute(ReadResourceDescriptionHandler.java:411)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:854)
> {code}
> The handling for this doesn't have the stuff I did for WFCORE-282.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:08:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 12:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.19049.1443456480203@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-832:
---------------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


Kabir, can you have a look in case your other work on r-r-d has already fixed this? If not, feel free to reassign back to me. I'm just hoping. ;)

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:20:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 12:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-315) NPE executing domain
	operation
In-Reply-To: <JIRA.12499957.1378305399000@Atlassian.JIRA>
References: <JIRA.12499957.1378305399000@Atlassian.JIRA>
	<JIRA.12499957.1378305399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.19125.1443457200820@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-315:
---------------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


Kabir, this is the same as the other one. If by chance your other work fixed this, please take credit. :) If not it's fine to assign back.

> NPE executing domain operation
> ------------------------------
>
>                 Key: WFCORE-315
>                 URL: https://issues.jboss.org/browse/WFCORE-315
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>
> {noformat}
> [ERROR] Request
> [ERROR] {
> [ERROR]     "operation" => "composite",
> [ERROR]     "address" => [],
> [ERROR]     "steps" => [
> [ERROR]         {
> [ERROR]             "address" => [("server-group" => "*")],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         },
> [ERROR]         {
> [ERROR]             "address" => [
> [ERROR]                 ("host" => "master"),
> [ERROR]                 ("server" => "*")
> [ERROR]             ],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         },
> [ERROR]         {
> [ERROR]             "address" => [("extension" => "*")],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         }
> [ERROR]     ],
> [ERROR]     "operation-headers" => {"roles" => "OPERATOR"}
> [ERROR] }
> {noformat}
> leads to  
> {noformat}
> [Host Controller] 16:34:53,544 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-12) JBAS014612: Operation ("composite") failed - address: ([]): java.lang.NullPointerException
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory.create(HostControllerExecutionSupport.java:167)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory.create(HostControllerExecutionSupport.java:181)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.addSteps(OperationSlaveStepHandler.java:108)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.executeTwoPhaseOperation(OperationCoordinatorStepHandler.java:201)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.execute(OperationCoordinatorStepHandler.java:124)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:103)
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:142) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:154) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$2.run(SubjectDoAsHandler.java:96) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$2.run(SubjectDoAsHandler.java:92) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller]   at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:92) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:86) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:50) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller]   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller]   at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:20:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 28 Sep 2015 12:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.19132.1443457200956@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112936#comment-13112936 ] 

Kabir Khan commented on WFCORE-832:
-----------------------------------

CLI to add the scoped roles is:
{code}
/core-service=management/access=authorization/server-group-scoped-role=main-maintainer:add(base-role=maintainer,server-groups=[main-server-group])
/core-service=management/access=authorization/server-group-scoped-role=other-monitor:add(base-role=monitor,server-groups=[other-server-group])
{code}
The WFCORE-994 work does not seem to fix this

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:25:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 12:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.19164.1443457500242@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112942#comment-13112942 ] 

Brian Stansberry commented on WFCORE-832:
-----------------------------------------

[~kabirkhan] with your WFCORE-994 branch, what's the result for this?

{code}
/server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{code}

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:26:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 28 Sep 2015 12:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.19175.1443457560437@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112945#comment-13112945 ] 

Kabir Khan commented on WFCORE-832:
-----------------------------------

Same as in the description:
{code}
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}
{code}

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:33:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 28 Sep 2015 12:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-315) NPE executing domain
	operation
In-Reply-To: <JIRA.12499957.1378305399000@Atlassian.JIRA>
References: <JIRA.12499957.1378305399000@Atlassian.JIRA>
	<JIRA.12499957.1378305399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.19197.1443457980150@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112950#comment-13112950 ] 

Kabir Khan commented on WFCORE-315:
-----------------------------------

I see this in CLI, so I think it works fine
{code}
[domain at localhost:9990 /] batch
[domain at localhost:9990 / #] /server-group=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] /host=master/server=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] /extension=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] run-batch --headers={roles=[operator]}
The batch executed successfully
{code}
Also https://github.com/wildfly/wildfly-core/pull/1122 adds a test for using /host=*/server=*:r-r-d

> NPE executing domain operation
> ------------------------------
>
>                 Key: WFCORE-315
>                 URL: https://issues.jboss.org/browse/WFCORE-315
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>
> {noformat}
> [ERROR] Request
> [ERROR] {
> [ERROR]     "operation" => "composite",
> [ERROR]     "address" => [],
> [ERROR]     "steps" => [
> [ERROR]         {
> [ERROR]             "address" => [("server-group" => "*")],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         },
> [ERROR]         {
> [ERROR]             "address" => [
> [ERROR]                 ("host" => "master"),
> [ERROR]                 ("server" => "*")
> [ERROR]             ],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         },
> [ERROR]         {
> [ERROR]             "address" => [("extension" => "*")],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         }
> [ERROR]     ],
> [ERROR]     "operation-headers" => {"roles" => "OPERATOR"}
> [ERROR] }
> {noformat}
> leads to  
> {noformat}
> [Host Controller] 16:34:53,544 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-12) JBAS014612: Operation ("composite") failed - address: ([]): java.lang.NullPointerException
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory.create(HostControllerExecutionSupport.java:167)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory.create(HostControllerExecutionSupport.java:181)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.addSteps(OperationSlaveStepHandler.java:108)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.executeTwoPhaseOperation(OperationCoordinatorStepHandler.java:201)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.execute(OperationCoordinatorStepHandler.java:124)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:103)
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:142) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:154) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$2.run(SubjectDoAsHandler.java:96) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$2.run(SubjectDoAsHandler.java:92) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller]   at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:92) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:86) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:50) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller]   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller]   at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:35:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 28 Sep 2015 12:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-315) NPE executing domain
	operation
In-Reply-To: <JIRA.12499957.1378305399000@Atlassian.JIRA>
References: <JIRA.12499957.1378305399000@Atlassian.JIRA>
	<JIRA.12499957.1378305399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.19203.1443458100138@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112950#comment-13112950 ] 

Kabir Khan edited comment on WFCORE-315 at 9/28/15 12:34 PM:
-------------------------------------------------------------

I see this in CLI, so I think it works fine
{code}
[domain at localhost:9990 /] batch
[domain at localhost:9990 / #] /server-group=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] /host=master/server=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] /extension=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] run-batch --headers={roles=[operator]}
The batch executed successfully
{code}
Also https://github.com/wildfly/wildfly-core/pull/1122 adds a test for using {code}/host=*/server=*:r-r-d{code}


was (Author: kabirkhan):
I see this in CLI, so I think it works fine
{code}
[domain at localhost:9990 /] batch
[domain at localhost:9990 / #] /server-group=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] /host=master/server=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] /extension=*:read-resource-description(access-control=trim-descriptions, operations=true)
[domain at localhost:9990 / #] run-batch --headers={roles=[operator]}
The batch executed successfully
{code}
Also https://github.com/wildfly/wildfly-core/pull/1122 adds a test for using /host=*/server=*:r-r-d

> NPE executing domain operation
> ------------------------------
>
>                 Key: WFCORE-315
>                 URL: https://issues.jboss.org/browse/WFCORE-315
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>
> {noformat}
> [ERROR] Request
> [ERROR] {
> [ERROR]     "operation" => "composite",
> [ERROR]     "address" => [],
> [ERROR]     "steps" => [
> [ERROR]         {
> [ERROR]             "address" => [("server-group" => "*")],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         },
> [ERROR]         {
> [ERROR]             "address" => [
> [ERROR]                 ("host" => "master"),
> [ERROR]                 ("server" => "*")
> [ERROR]             ],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         },
> [ERROR]         {
> [ERROR]             "address" => [("extension" => "*")],
> [ERROR]             "operation" => "read-resource-description",
> [ERROR]             "access-control" => "trim-descriptions",
> [ERROR]             "operations" => true
> [ERROR]         }
> [ERROR]     ],
> [ERROR]     "operation-headers" => {"roles" => "OPERATOR"}
> [ERROR] }
> {noformat}
> leads to  
> {noformat}
> [Host Controller] 16:34:53,544 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-12) JBAS014612: Operation ("composite") failed - address: ([]): java.lang.NullPointerException
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory.create(HostControllerExecutionSupport.java:167)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory.create(HostControllerExecutionSupport.java:181)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.addSteps(OperationSlaveStepHandler.java:108)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.executeTwoPhaseOperation(OperationCoordinatorStepHandler.java:201)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.execute(OperationCoordinatorStepHandler.java:124)
> [Host Controller]   at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:103)
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:142) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:154) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$2.run(SubjectDoAsHandler.java:96) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$2.run(SubjectDoAsHandler.java:92) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller]   at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:92) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:86) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:50) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87) [wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Host Controller]   at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta12.jar:1.0.0.Beta12]
> [Host Controller]   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller]   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller]   at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:38:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 12:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1017) Reload operation causes
 crash of EAP server
In-Reply-To: <JIRA.12585338.1442567011000@Atlassian.JIRA>
References: <JIRA.12585338.1442567011000@Atlassian.JIRA>
	<JIRA.12585338.1442567011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585338.1442567011000.19215.1443458280177@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-5361 to WFCORE-1017:
------------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-1017  (was: WFLY-5361)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 2.0.0.CR1
                           (was: 10.0.0.CR1)


> Reload operation causes crash of EAP server
> -------------------------------------------
>
>                 Key: WFCORE-1017
>                 URL: https://issues.jboss.org/browse/WFCORE-1017
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>         Environment: Fedora 22, RHEL 7 ++ OpenJDK 8 - crash of EAP server
> Fedora 22, RHEL 7 ++ IBM Java 1.8 - crash of JVM where runs the EAP server
> {panel}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {panel}
>            Reporter: Erich Duda
>            Assignee: Alexey Loubyansky
>         Attachments: javacore.20150917.161241.19157.0002.txt, server-openjdk.log, Snap.20150917.161241.19157.0003.trc
>
>
> Repeated execution of reload request causes EAP server crash.
> {panel}
> 10:43:15,179 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1 at 3d119a3c" failed: java.lang.IllegalArgumentException: Container is shutting down
>         at org.jboss.msc.service.ServiceControllerImpl.internalSetMode(ServiceControllerImpl.java:762) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.setMode(ServiceControllerImpl.java:753) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.transition(ProcessReloadHandler.java:90) [wildfly-controller-2.0.0.Beta4.jar:2.0.0.Beta4]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [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_60]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {panel}
> On IBM Java reload resquests cause even JVM crash.
> {panel}
> #0: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x8a455f) [0x7f44cce6055f]
> #1: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1042f1) [0x7f44cc6c02f1]
> #2: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x255ee) [0x7f44d8b515ee]
> #3: /lib64/libpthread.so.0(+0x10430) [0x7f44dafd9430]
> #4: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x74909e) [0x7f44ccd0509e]
> #5: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x749372) [0x7f44ccd05372]
> #6: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x437922) [0x7f44cc9f3922]
> #7: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x4385bb) [0x7f44cc9f45bb]
> #8: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x448e10) [0x7f44cca04e10]
> #9: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x449855) [0x7f44cca05855]
> #10: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dd5d) [0x7f44cca09d5d]
> #11: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #12: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #13: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #14: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #15: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #16: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44ec75) [0x7f44cca0ac75]
> #17: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44effb) [0x7f44cca0affb]
> #18: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cd94d) [0x7f44cc88994d]
> #19: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cdc19) [0x7f44cc889c19]
> #20: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cee94) [0x7f44cc88ae94]
> #21: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7c748b) [0x7f44ccd8348b]
> #22: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7cee4c) [0x7f44ccd8ae4c]
> #23: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10c7b5) [0x7f44cc6c87b5]
> #24: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10dcab) [0x7f44cc6c9cab]
> #25: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #26: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10fdf0) [0x7f44cc6cbdf0]
> #27: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1110ed) [0x7f44cc6cd0ed]
> #28: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #29: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x111a04) [0x7f44cc6cda04]
> Unhandled exception
> Type=Segmentation error vmState=0x00051cff
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F44D920CD90 Handler2=00007F44D8B513F0 InaccessibleAddress=0000000000000000
> RDI=00007F440613D710 RSI=FFFFFFFFFFDF3B65 RAX=0000000000000000 RBX=00007F4406141390
> RCX=0000000000000026 RDX=0000000000000001 R8=00007F44CCF4EA52 R9=0000000000000000
> R10=00007F4406145740 R11=0000000000000003 R12=00007F44076AEF00 R13=0000000000000000
> R14=0000000000000000 R15=0000000000000000
> RIP=00007F44CCD0509E GS=0000 FS=0000 RSP=00007F44C9A84C20
> EFlags=0000000000210246 CS=0033 RBP=0000000000000000 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f44003b6e6f (f: 3894895,000000, d: 6,913462e-310)
> xmm1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm2 616c2f6176616a4c (f: 1986095744,000000, d: 1,981285e+161)
> xmm3 6a00656c62617468 (f: 1650553984,000000, d: 4,016150e+202)
> xmm4 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm5 03d303d203d103d0 (f: 64029648,000000, d: 3,048729e-290)
> xmm6 49676e697274532f (f: 1920226048,000000, d: 4,180283e+45)
> xmm7 4573646e756f4266 (f: 1970225792,000000, d: 3,751018e+26)
> xmm8 03d603d503d403d3 (f: 64226260,000000, d: 3,529736e-290)
> xmm9 03de03dd03dc03db (f: 64750556,000000, d: 4,812424e-290)
> xmm10 03e603e503e403e3 (f: 65274852,000000, d: 7,059551e-290)
> xmm11 03ee03ed03ec03eb (f: 65799148,000000, d: 9,624926e-290)
> xmm12 03f603f503f403f3 (f: 66323444,000000, d: 1,411926e-289)
> xmm13 03fe03fd03fc03fb (f: 66847740,000000, d: 1,925001e-289)
> xmm14 0406040504040403 (f: 67372032,000000, d: 2,823883e-289)
> xmm15 040e040d040c040b (f: 67896328,000000, d: 3,850033e-289)
> Module=/opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so
> Module_base_address=00007F44CC5BC000
> Method_being_compiled=org/jboss/as/controller/OperationContextImpl$ContextServiceBuilder.install()Lorg/jboss/msc/service/ServiceController;
> Target=2_80_20150630_255633 (Linux 4.1.6-201.fc22.x86_64)
> CPU=amd64 (8 logical CPUs) (0x3d3def000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F44CCD0509E [libj9jit28.so+0x74909e])
> (0x00007F44CCD05372 [libj9jit28.so+0x749372])
> (0x00007F44CC9F3922 [libj9jit28.so+0x437922])
> (0x00007F44CC9F45BB [libj9jit28.so+0x4385bb])
> (0x00007F44CCA04E10 [libj9jit28.so+0x448e10])
> (0x00007F44CCA05855 [libj9jit28.so+0x449855])
> (0x00007F44CCA09D5D [libj9jit28.so+0x44dd5d])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA0AC75 [libj9jit28.so+0x44ec75])
> (0x00007F44CCA0AFFB [libj9jit28.so+0x44effb])
> (0x00007F44CC88994D [libj9jit28.so+0x2cd94d])
> (0x00007F44CC889C19 [libj9jit28.so+0x2cdc19])
> (0x00007F44CC88AE94 [libj9jit28.so+0x2cee94])
> (0x00007F44CCD8348B [libj9jit28.so+0x7c748b])
> (0x00007F44CCD8AE4C [libj9jit28.so+0x7cee4c])
> (0x00007F44CC6C87B5 [libj9jit28.so+0x10c7b5])
> (0x00007F44CC6C9CAB [libj9jit28.so+0x10dcab])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CBDF0 [libj9jit28.so+0x10fdf0])
> (0x00007F44CC6CD0ED [libj9jit28.so+0x1110ed])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CDA04 [libj9jit28.so+0x111a04])
> (0x00007F44D8F8E9EC [libj9thr28.so+0x99ec])
> (0x00007F44DAFD0555 [libpthread.so.0+0x7555])
> clone+0x6d (0x00007F44DA8F0B9D [libc.so.6+0x102b9d])
> {panel}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:42:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 12:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1017) Reload operation causes
 crash of EAP server
In-Reply-To: <JIRA.12585338.1442567011000@Atlassian.JIRA>
References: <JIRA.12585338.1442567011000@Atlassian.JIRA>
	<JIRA.12585338.1442567011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585338.1442567011000.19236.1443458520378@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112954#comment-13112954 ] 

Brian Stansberry commented on WFCORE-1017:
------------------------------------------

Please attach a reproducer, including source code.

The attached server-openjdk.log indicates that something has triggered the shutdown hook that stops the server in response to signals:

{code}
10:43:15,140 INFO  [org.jboss.as.server] (Thread-3) WFLYSRV0220: Server shutdown has been requested.
{code}

> Reload operation causes crash of EAP server
> -------------------------------------------
>
>                 Key: WFCORE-1017
>                 URL: https://issues.jboss.org/browse/WFCORE-1017
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>         Environment: Fedora 22, RHEL 7 ++ OpenJDK 8 - crash of EAP server
> Fedora 22, RHEL 7 ++ IBM Java 1.8 - crash of JVM where runs the EAP server
> {panel}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {panel}
>            Reporter: Erich Duda
>            Assignee: Alexey Loubyansky
>         Attachments: javacore.20150917.161241.19157.0002.txt, server-openjdk.log, Snap.20150917.161241.19157.0003.trc
>
>
> Repeated execution of reload request causes EAP server crash.
> {panel}
> 10:43:15,179 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1 at 3d119a3c" failed: java.lang.IllegalArgumentException: Container is shutting down
>         at org.jboss.msc.service.ServiceControllerImpl.internalSetMode(ServiceControllerImpl.java:762) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.setMode(ServiceControllerImpl.java:753) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.transition(ProcessReloadHandler.java:90) [wildfly-controller-2.0.0.Beta4.jar:2.0.0.Beta4]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [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_60]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {panel}
> On IBM Java reload resquests cause even JVM crash.
> {panel}
> #0: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x8a455f) [0x7f44cce6055f]
> #1: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1042f1) [0x7f44cc6c02f1]
> #2: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x255ee) [0x7f44d8b515ee]
> #3: /lib64/libpthread.so.0(+0x10430) [0x7f44dafd9430]
> #4: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x74909e) [0x7f44ccd0509e]
> #5: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x749372) [0x7f44ccd05372]
> #6: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x437922) [0x7f44cc9f3922]
> #7: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x4385bb) [0x7f44cc9f45bb]
> #8: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x448e10) [0x7f44cca04e10]
> #9: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x449855) [0x7f44cca05855]
> #10: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dd5d) [0x7f44cca09d5d]
> #11: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #12: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #13: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #14: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #15: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #16: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44ec75) [0x7f44cca0ac75]
> #17: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44effb) [0x7f44cca0affb]
> #18: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cd94d) [0x7f44cc88994d]
> #19: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cdc19) [0x7f44cc889c19]
> #20: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cee94) [0x7f44cc88ae94]
> #21: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7c748b) [0x7f44ccd8348b]
> #22: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7cee4c) [0x7f44ccd8ae4c]
> #23: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10c7b5) [0x7f44cc6c87b5]
> #24: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10dcab) [0x7f44cc6c9cab]
> #25: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #26: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10fdf0) [0x7f44cc6cbdf0]
> #27: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1110ed) [0x7f44cc6cd0ed]
> #28: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #29: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x111a04) [0x7f44cc6cda04]
> Unhandled exception
> Type=Segmentation error vmState=0x00051cff
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F44D920CD90 Handler2=00007F44D8B513F0 InaccessibleAddress=0000000000000000
> RDI=00007F440613D710 RSI=FFFFFFFFFFDF3B65 RAX=0000000000000000 RBX=00007F4406141390
> RCX=0000000000000026 RDX=0000000000000001 R8=00007F44CCF4EA52 R9=0000000000000000
> R10=00007F4406145740 R11=0000000000000003 R12=00007F44076AEF00 R13=0000000000000000
> R14=0000000000000000 R15=0000000000000000
> RIP=00007F44CCD0509E GS=0000 FS=0000 RSP=00007F44C9A84C20
> EFlags=0000000000210246 CS=0033 RBP=0000000000000000 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f44003b6e6f (f: 3894895,000000, d: 6,913462e-310)
> xmm1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm2 616c2f6176616a4c (f: 1986095744,000000, d: 1,981285e+161)
> xmm3 6a00656c62617468 (f: 1650553984,000000, d: 4,016150e+202)
> xmm4 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm5 03d303d203d103d0 (f: 64029648,000000, d: 3,048729e-290)
> xmm6 49676e697274532f (f: 1920226048,000000, d: 4,180283e+45)
> xmm7 4573646e756f4266 (f: 1970225792,000000, d: 3,751018e+26)
> xmm8 03d603d503d403d3 (f: 64226260,000000, d: 3,529736e-290)
> xmm9 03de03dd03dc03db (f: 64750556,000000, d: 4,812424e-290)
> xmm10 03e603e503e403e3 (f: 65274852,000000, d: 7,059551e-290)
> xmm11 03ee03ed03ec03eb (f: 65799148,000000, d: 9,624926e-290)
> xmm12 03f603f503f403f3 (f: 66323444,000000, d: 1,411926e-289)
> xmm13 03fe03fd03fc03fb (f: 66847740,000000, d: 1,925001e-289)
> xmm14 0406040504040403 (f: 67372032,000000, d: 2,823883e-289)
> xmm15 040e040d040c040b (f: 67896328,000000, d: 3,850033e-289)
> Module=/opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so
> Module_base_address=00007F44CC5BC000
> Method_being_compiled=org/jboss/as/controller/OperationContextImpl$ContextServiceBuilder.install()Lorg/jboss/msc/service/ServiceController;
> Target=2_80_20150630_255633 (Linux 4.1.6-201.fc22.x86_64)
> CPU=amd64 (8 logical CPUs) (0x3d3def000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F44CCD0509E [libj9jit28.so+0x74909e])
> (0x00007F44CCD05372 [libj9jit28.so+0x749372])
> (0x00007F44CC9F3922 [libj9jit28.so+0x437922])
> (0x00007F44CC9F45BB [libj9jit28.so+0x4385bb])
> (0x00007F44CCA04E10 [libj9jit28.so+0x448e10])
> (0x00007F44CCA05855 [libj9jit28.so+0x449855])
> (0x00007F44CCA09D5D [libj9jit28.so+0x44dd5d])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA0AC75 [libj9jit28.so+0x44ec75])
> (0x00007F44CCA0AFFB [libj9jit28.so+0x44effb])
> (0x00007F44CC88994D [libj9jit28.so+0x2cd94d])
> (0x00007F44CC889C19 [libj9jit28.so+0x2cdc19])
> (0x00007F44CC88AE94 [libj9jit28.so+0x2cee94])
> (0x00007F44CCD8348B [libj9jit28.so+0x7c748b])
> (0x00007F44CCD8AE4C [libj9jit28.so+0x7cee4c])
> (0x00007F44CC6C87B5 [libj9jit28.so+0x10c7b5])
> (0x00007F44CC6C9CAB [libj9jit28.so+0x10dcab])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CBDF0 [libj9jit28.so+0x10fdf0])
> (0x00007F44CC6CD0ED [libj9jit28.so+0x1110ed])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CDA04 [libj9jit28.so+0x111a04])
> (0x00007F44D8F8E9EC [libj9thr28.so+0x99ec])
> (0x00007F44DAFD0555 [libpthread.so.0+0x7555])
> clone+0x6d (0x00007F44DA8F0B9D [libc.so.6+0x102b9d])
> {panel}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:42:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 28 Sep 2015 12:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5421) UnsupportedOperationException
 during singleton service view change
In-Reply-To: <JIRA.12586317.1443458463000@Atlassian.JIRA>
References: <JIRA.12586317.1443458463000@Atlassian.JIRA>
	<JIRA.12586317.1443458463184@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586317.1443458463000.19239.1443458520459@Atlassian.JIRA>

Paul Ferraro created WFLY-5421:
----------------------------------

             Summary: UnsupportedOperationException during singleton service view change
                 Key: WFLY-5421
                 URL: https://issues.jboss.org/browse/WFLY-5421
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.CR2
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
            Priority: Critical


{noformat}
2015-09-28 10:32:03,355 WARN  [org.infinispan.notifications.cachelistener.CacheNotifierImpl] (notification-thread--p4-t1) ISPN000331: Unable to invoke method public void org.wildfly.clustering.server.group.CacheGroup.topologyChanged(org.infinispan.notifications.cachelistener.event.TopologyChangedEvent) on Object instance org.wildfly.clustering.server.group.CacheGroup at 5bcbba4a : java.lang.UnsupportedOperationException: Not supported in this implementation since additional locking is required and cannot directly be delegated to multiple calls to ConcurrentHashMap
	at org.infinispan.util.concurrent.ConcurrentHashSet.removeAll(ConcurrentHashSet.java:110)
	at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.lambda$membershipChanged$7(CacheServiceProviderRegistry.java:161)
	at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.execute(StampedLockServiceExecutor.java:42)
	at org.wildfly.clustering.server.provider.CacheServiceProviderRegistry.membershipChanged(CacheServiceProviderRegistry.java:150)
	at org.wildfly.clustering.server.group.CacheGroup.lambda$topologyChanged$9(CacheGroup.java:134)
	at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.execute(StampedLockServiceExecutor.java:42)
	at org.wildfly.clustering.server.group.CacheGroup.topologyChanged(CacheGroup.java:120)
	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.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
	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
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:44:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 12:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1017) Reload operation causes
 crash of EAP server
In-Reply-To: <JIRA.12585338.1442567011000@Atlassian.JIRA>
References: <JIRA.12585338.1442567011000@Atlassian.JIRA>
	<JIRA.12585338.1442567011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585338.1442567011000.19256.1443458640262@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1017:
----------------------------------------

    Assignee: Tomaz Cerar  (was: Alexey Loubyansky)


> Reload operation causes crash of EAP server
> -------------------------------------------
>
>                 Key: WFCORE-1017
>                 URL: https://issues.jboss.org/browse/WFCORE-1017
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR1
>         Environment: Fedora 22, RHEL 7 ++ OpenJDK 8 - crash of EAP server
> Fedora 22, RHEL 7 ++ IBM Java 1.8 - crash of JVM where runs the EAP server
> {panel}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {panel}
>            Reporter: Erich Duda
>            Assignee: Tomaz Cerar
>         Attachments: javacore.20150917.161241.19157.0002.txt, server-openjdk.log, Snap.20150917.161241.19157.0003.trc
>
>
> Repeated execution of reload request causes EAP server crash.
> {panel}
> 10:43:15,179 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1 at 3d119a3c" failed: java.lang.IllegalArgumentException: Container is shutting down
>         at org.jboss.msc.service.ServiceControllerImpl.internalSetMode(ServiceControllerImpl.java:762) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.setMode(ServiceControllerImpl.java:753) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.transition(ProcessReloadHandler.java:90) [wildfly-controller-2.0.0.Beta4.jar:2.0.0.Beta4]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [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_60]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {panel}
> On IBM Java reload resquests cause even JVM crash.
> {panel}
> #0: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x8a455f) [0x7f44cce6055f]
> #1: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1042f1) [0x7f44cc6c02f1]
> #2: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x255ee) [0x7f44d8b515ee]
> #3: /lib64/libpthread.so.0(+0x10430) [0x7f44dafd9430]
> #4: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x74909e) [0x7f44ccd0509e]
> #5: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x749372) [0x7f44ccd05372]
> #6: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x437922) [0x7f44cc9f3922]
> #7: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x4385bb) [0x7f44cc9f45bb]
> #8: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x448e10) [0x7f44cca04e10]
> #9: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x449855) [0x7f44cca05855]
> #10: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dd5d) [0x7f44cca09d5d]
> #11: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #12: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #13: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #14: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #15: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #16: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44ec75) [0x7f44cca0ac75]
> #17: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44effb) [0x7f44cca0affb]
> #18: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cd94d) [0x7f44cc88994d]
> #19: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cdc19) [0x7f44cc889c19]
> #20: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cee94) [0x7f44cc88ae94]
> #21: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7c748b) [0x7f44ccd8348b]
> #22: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7cee4c) [0x7f44ccd8ae4c]
> #23: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10c7b5) [0x7f44cc6c87b5]
> #24: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10dcab) [0x7f44cc6c9cab]
> #25: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #26: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10fdf0) [0x7f44cc6cbdf0]
> #27: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1110ed) [0x7f44cc6cd0ed]
> #28: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #29: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x111a04) [0x7f44cc6cda04]
> Unhandled exception
> Type=Segmentation error vmState=0x00051cff
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F44D920CD90 Handler2=00007F44D8B513F0 InaccessibleAddress=0000000000000000
> RDI=00007F440613D710 RSI=FFFFFFFFFFDF3B65 RAX=0000000000000000 RBX=00007F4406141390
> RCX=0000000000000026 RDX=0000000000000001 R8=00007F44CCF4EA52 R9=0000000000000000
> R10=00007F4406145740 R11=0000000000000003 R12=00007F44076AEF00 R13=0000000000000000
> R14=0000000000000000 R15=0000000000000000
> RIP=00007F44CCD0509E GS=0000 FS=0000 RSP=00007F44C9A84C20
> EFlags=0000000000210246 CS=0033 RBP=0000000000000000 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f44003b6e6f (f: 3894895,000000, d: 6,913462e-310)
> xmm1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm2 616c2f6176616a4c (f: 1986095744,000000, d: 1,981285e+161)
> xmm3 6a00656c62617468 (f: 1650553984,000000, d: 4,016150e+202)
> xmm4 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm5 03d303d203d103d0 (f: 64029648,000000, d: 3,048729e-290)
> xmm6 49676e697274532f (f: 1920226048,000000, d: 4,180283e+45)
> xmm7 4573646e756f4266 (f: 1970225792,000000, d: 3,751018e+26)
> xmm8 03d603d503d403d3 (f: 64226260,000000, d: 3,529736e-290)
> xmm9 03de03dd03dc03db (f: 64750556,000000, d: 4,812424e-290)
> xmm10 03e603e503e403e3 (f: 65274852,000000, d: 7,059551e-290)
> xmm11 03ee03ed03ec03eb (f: 65799148,000000, d: 9,624926e-290)
> xmm12 03f603f503f403f3 (f: 66323444,000000, d: 1,411926e-289)
> xmm13 03fe03fd03fc03fb (f: 66847740,000000, d: 1,925001e-289)
> xmm14 0406040504040403 (f: 67372032,000000, d: 2,823883e-289)
> xmm15 040e040d040c040b (f: 67896328,000000, d: 3,850033e-289)
> Module=/opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so
> Module_base_address=00007F44CC5BC000
> Method_being_compiled=org/jboss/as/controller/OperationContextImpl$ContextServiceBuilder.install()Lorg/jboss/msc/service/ServiceController;
> Target=2_80_20150630_255633 (Linux 4.1.6-201.fc22.x86_64)
> CPU=amd64 (8 logical CPUs) (0x3d3def000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F44CCD0509E [libj9jit28.so+0x74909e])
> (0x00007F44CCD05372 [libj9jit28.so+0x749372])
> (0x00007F44CC9F3922 [libj9jit28.so+0x437922])
> (0x00007F44CC9F45BB [libj9jit28.so+0x4385bb])
> (0x00007F44CCA04E10 [libj9jit28.so+0x448e10])
> (0x00007F44CCA05855 [libj9jit28.so+0x449855])
> (0x00007F44CCA09D5D [libj9jit28.so+0x44dd5d])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA0AC75 [libj9jit28.so+0x44ec75])
> (0x00007F44CCA0AFFB [libj9jit28.so+0x44effb])
> (0x00007F44CC88994D [libj9jit28.so+0x2cd94d])
> (0x00007F44CC889C19 [libj9jit28.so+0x2cdc19])
> (0x00007F44CC88AE94 [libj9jit28.so+0x2cee94])
> (0x00007F44CCD8348B [libj9jit28.so+0x7c748b])
> (0x00007F44CCD8AE4C [libj9jit28.so+0x7cee4c])
> (0x00007F44CC6C87B5 [libj9jit28.so+0x10c7b5])
> (0x00007F44CC6C9CAB [libj9jit28.so+0x10dcab])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CBDF0 [libj9jit28.so+0x10fdf0])
> (0x00007F44CC6CD0ED [libj9jit28.so+0x1110ed])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CDA04 [libj9jit28.so+0x111a04])
> (0x00007F44D8F8E9EC [libj9thr28.so+0x99ec])
> (0x00007F44DAFD0555 [libpthread.so.0+0x7555])
> clone+0x6d (0x00007F44DA8F0B9D [libc.so.6+0x102b9d])
> {panel}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 12:48:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 12:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.19286.1443458880207@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112956#comment-13112956 ] 

Brian Stansberry commented on WFCORE-832:
-----------------------------------------

Thanks. I assume the issue then is when it is working out the exceptions it is only based on the last PathElement in the target address. It's not realizing the server-group=a/deployment=* might be an exception.

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 13:03:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 28 Sep 2015 13:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1018)
 PeriodicSizeRotatingFileHandler's are always replaced during boot
In-Reply-To: <JIRA.12586318.1443459748000@Atlassian.JIRA>
References: <JIRA.12586318.1443459748000@Atlassian.JIRA>
	<JIRA.12586318.1443459748572@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586318.1443459748000.19302.1443459780146@Atlassian.JIRA>

James Perkins created WFCORE-1018:
-------------------------------------

             Summary: PeriodicSizeRotatingFileHandler's are always replaced during boot
                 Key: WFCORE-1018
                 URL: https://issues.jboss.org/browse/WFCORE-1018
             Project: WildFly Core
          Issue Type: Bug
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 2.0.0.CR6


A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 13:14:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 13:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-323) Validate composite operation
 steps just before executing them
In-Reply-To: <JIRA.12482292.1357761533000@Atlassian.JIRA>
References: <JIRA.12482292.1357761533000@Atlassian.JIRA>
	<JIRA.12482292.1357761533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482292.1357761533000.19316.1443460440214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-323:
---------------------------------------

    Assignee:     (was: Brian Stansberry)


> Validate composite operation steps just before executing them
> -------------------------------------------------------------
>
>                 Key: WFCORE-323
>                 URL: https://issues.jboss.org/browse/WFCORE-323
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>              Labels: EAP
>
> Say we have a composite operation with 2 steps:
> 1) /extension=org.jboss.as.messaging:add
> 2) /subsystem=messaging:add
> This will fail:
> Failed to execute batch: JBAS014739: No handler for add at address
> [("subsystem" => "messaging")] 
> This fails because at the time of validation the /subsystem=messaging:add is not valid.
> To illustrate, the execution order is
> Validate 1-2
> 1
> 2
> A possible solution is to convert this to the following:
> V1
> 1
> V2 (works now because 1 has registered the subsystem API)
> 2
> I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 13:14:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 13:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-329) Allow duplication of
 configuration parts via management API
In-Reply-To: <JIRA.12486249.1362468208000@Atlassian.JIRA>
References: <JIRA.12486249.1362468208000@Atlassian.JIRA>
	<JIRA.12486249.1362468208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486249.1362468208000.19320.1443460440293@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-329:
---------------------------------------

    Assignee:     (was: Brian Stansberry)


> Allow duplication of configuration parts via management API
> -----------------------------------------------------------
>
>                 Key: WFCORE-329
>                 URL: https://issues.jboss.org/browse/WFCORE-329
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Alex Ont
>
> Allow the possibility to read part of the configuration via management API, modify it and add it back under a new id, without knowing the specific details of the resource.
> This would allow for example adding a new server group configured exactly as an existing, creating a new resource (datasource, etc.) based on an existing one or even creating a profile based on a given one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 14:27:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 28 Sep 2015 14:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5401) Bump the schema and model
 version of the Undertow subsystem
In-Reply-To: <JIRA.12585958.1443098748000@Atlassian.JIRA>
References: <JIRA.12585958.1443098748000@Atlassian.JIRA>
	<JIRA.12585958.1443098748000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585958.1443098748000.19533.1443464820889@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112985#comment-13112985 ] 

Darran Lofthouse commented on WFLY-5401:
----------------------------------------

Changes for this issue can be found in the following branch: -
  https://github.com/darranl/wildfly/tree/WFLY-5401

> Bump the schema and model version of the Undertow subsystem
> -----------------------------------------------------------
>
>                 Key: WFLY-5401
>                 URL: https://issues.jboss.org/browse/WFLY-5401
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 18:20:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 28 Sep 2015 18:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5420) jboss-javaee-7.0-wildfly POMs
 (and friends) need updating to Wildfly 10CR2
In-Reply-To: <JIRA.12586294.1443448204000@Atlassian.JIRA>
References: <JIRA.12586294.1443448204000@Atlassian.JIRA>
	<JIRA.12586294.1443448204000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586294.1443448204000.19911.1443478800318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-5420:
---------------------------------

    Assignee: Tomaz Cerar  (was: Jason Greene)


> jboss-javaee-7.0-wildfly POMs (and friends) need updating to Wildfly 10CR2
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5420
>                 URL: https://issues.jboss.org/browse/WFLY-5420
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.0.0.CR2
>            Reporter: The Alchemist
>            Assignee: Tomaz Cerar
>
> http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22jboss-javaee-7.0-wildfly%22
> 10.0.0.Beta2  is the version of the latest POMs.  Perhaps someone just needs to do a {{mvn deploy}}?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 18:38:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 28 Sep 2015 18:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5420) jboss-javaee-7.0-wildfly POMs
 (and friends) need updating to Wildfly 10CR2
In-Reply-To: <JIRA.12586294.1443448204000@Atlassian.JIRA>
References: <JIRA.12586294.1443448204000@Atlassian.JIRA>
	<JIRA.12586294.1443448204000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586294.1443448204000.19939.1443479880236@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-5420.
-------------------------------
    Fix Version/s: 10.0.0.CR2
       Resolution: Done


Done

> jboss-javaee-7.0-wildfly POMs (and friends) need updating to Wildfly 10CR2
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5420
>                 URL: https://issues.jboss.org/browse/WFLY-5420
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.0.0.CR2
>            Reporter: The Alchemist
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR2
>
>
> http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22jboss-javaee-7.0-wildfly%22
> 10.0.0.Beta2  is the version of the latest POMs.  Perhaps someone just needs to do a {{mvn deploy}}?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 20:14:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 28 Sep 2015 20:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4618) JASPIC authentication
 processed on unsecured ressources
In-Reply-To: <JIRA.12571241.1431335247000@Atlassian.JIRA>
References: <JIRA.12571241.1431335247000@Atlassian.JIRA>
	<JIRA.12571241.1431335247000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571241.1431335247000.20013.1443485640134@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reopened WFLY-4618:
----------------------------------


> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
>                 Key: WFLY-4618
>                 URL: https://issues.jboss.org/browse/WFLY-4618
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (JBoss Web), Web (Undertow)
>    Affects Versions: 8.2.0.Final, 9.0.0.CR1
>            Reporter: Gernot M?ller
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha4
>
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 28 20:34:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 28 Sep 2015 20:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4618) JASPIC authentication
 processed on unsecured ressources
In-Reply-To: <JIRA.12571241.1431335247000@Atlassian.JIRA>
References: <JIRA.12571241.1431335247000@Atlassian.JIRA>
	<JIRA.12571241.1431335247000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571241.1431335247000.20053.1443486840189@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-4618.
----------------------------------
    Fix Version/s:     (was: 10.0.0.Alpha4)
       Resolution: Rejected


Change is being reverted, as it violates JASPIC spec. a module must check the "javax.security.auth.message.MessagePolicy.isMandatory" property, and if this is false then it should still return SUCCESS even if auth was not successful.

> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
>                 Key: WFLY-4618
>                 URL: https://issues.jboss.org/browse/WFLY-4618
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (JBoss Web), Web (Undertow)
>    Affects Versions: 8.2.0.Final, 9.0.0.CR1
>            Reporter: Gernot M?ller
>            Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 28 20:38:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 20:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1016) NPE or AssertionError if op
 is cancelled on slave between sending prepare and receiving commit/rollback
In-Reply-To: <JIRA.12586249.1443389718000@Atlassian.JIRA>
References: <JIRA.12586249.1443389718000@Atlassian.JIRA>
	<JIRA.12586249.1443389718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586249.1443389718000.20055.1443487080053@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1016:
-------------------------------------
    Description: 
OperationCancellationTestCase showed this failure:

{code}
2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) block requested by testSlaveBlockCompletionCancelSlave for slave/undefined(COMMIT)
2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) will block at COMMIT for 20000
2015-09-23 06:43:40,164 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 71) WFLYCTL0352: Cancelling operation 'block' with id '1900489784' running on thread 'Host Controller Service Threads - 82'
2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) Exception in thread "Host Controller Service Threads - 82" java.lang.AssertionError
2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.completed(TransactionalProtocolOperationHandler.java:475)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at javax.security.auth.Subject.doAs(Subject.java:360)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.lang.Thread.run(Thread.java:745)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}

What happens here is the slave HC executing the 'block' op has sent a prepare message to the master, and then when the commit has not come back yet the test driver triggers a cancel on the slave. At this point the thread running the 'block' op returns and tries to send the final result to the master. But it fails because the prepare logic has nulled out the responseChannel field, and the commit message has not arrived yet to restore a new one.

If assertions weren't enabled, the result would be an NPE when the null responseChannel is used.

I don't see any reason for null out the responseChannel.

  was:
OperationCancellationTestCase showed this failure:

{code}
2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) block requested by testSlaveBlockCompletionCancelSlave for slave/undefined(COMMIT)
2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) will block at COMMIT for 20000
2015-09-23 06:43:40,164 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 71) WFLYCTL0352: Cancelling operation 'block' with id '1900489784' running on thread 'Host Controller Service Threads - 82'
2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) Exception in thread "Host Controller Service Threads - 82" java.lang.AssertionError
2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.completed(TransactionalProtocolOperationHandler.java:475)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at javax.security.auth.Subject.doAs(Subject.java:360)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.lang.Thread.run(Thread.java:745)
2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}

What happens here is the slave HC executing the 'block' op has sent a prepare message to the master, and then when the commit has not come back yet the test driver triggers a cancel on the slave. At this point the thread running the 'block' op returns and tries to send the final result to the master. But it fails because the prepare logic has nulled out the requestContext field, and the commit message has not arrived yet to restore a new one.

If assertions weren't enabled, the result would be an NPE when the null requestContext is used.

I don't see any reason for null out the requestContext.



> NPE or AssertionError if op is cancelled on slave between sending prepare and receiving commit/rollback
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1016
>                 URL: https://issues.jboss.org/browse/WFCORE-1016
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR5
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> OperationCancellationTestCase showed this failure:
> {code}
> 2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) block requested by testSlaveBlockCompletionCancelSlave for slave/undefined(COMMIT)
> 2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) will block at COMMIT for 20000
> 2015-09-23 06:43:40,164 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 71) WFLYCTL0352: Cancelling operation 'block' with id '1900489784' running on thread 'Host Controller Service Threads - 82'
> 2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) Exception in thread "Host Controller Service Threads - 82" java.lang.AssertionError
> 2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.completed(TransactionalProtocolOperationHandler.java:475)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at javax.security.auth.Subject.doAs(Subject.java:360)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.lang.Thread.run(Thread.java:745)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> What happens here is the slave HC executing the 'block' op has sent a prepare message to the master, and then when the commit has not come back yet the test driver triggers a cancel on the slave. At this point the thread running the 'block' op returns and tries to send the final result to the master. But it fails because the prepare logic has nulled out the responseChannel field, and the commit message has not arrived yet to restore a new one.
> If assertions weren't enabled, the result would be an NPE when the null responseChannel is used.
> I don't see any reason for null out the responseChannel.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 20:48:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Sep 2015 20:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1016) NPE or AssertionError if op
 is cancelled on slave between sending prepare and receiving commit/rollback
In-Reply-To: <JIRA.12586249.1443389718000@Atlassian.JIRA>
References: <JIRA.12586249.1443389718000@Atlassian.JIRA>
	<JIRA.12586249.1443389718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586249.1443389718000.20089.1443487680048@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113048#comment-13113048 ] 

Brian Stansberry commented on WFCORE-1016:
------------------------------------------

Turns out the responseChannel needs to be nulled for each request/response pair, as the client will only expect one response per request. Nulling the responseChannel is meant to ensure the server doesn't try to send > 1 response per request.

So the fix is deal with this situation where the responseChannel is null because the prepare response has been set, but then a final response is ready before the client has send the commit/rollback message.

> NPE or AssertionError if op is cancelled on slave between sending prepare and receiving commit/rollback
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1016
>                 URL: https://issues.jboss.org/browse/WFCORE-1016
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR5
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.0.CR6
>
>
> OperationCancellationTestCase showed this failure:
> {code}
> 2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) block requested by testSlaveBlockCompletionCancelSlave for slave/undefined(COMMIT)
> 2015-09-23 06:43:40,147 INFO  [org.jboss.as.test.integration.management.extension.blocker.BlockerExtension] (Host Controller Service Threads - 82) will block at COMMIT for 20000
> 2015-09-23 06:43:40,164 INFO  [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 71) WFLYCTL0352: Cancelling operation 'block' with id '1900489784' running on thread 'Host Controller Service Threads - 82'
> 2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) Exception in thread "Host Controller Service Threads - 82" java.lang.AssertionError
> 2015-09-23 06:43:40,185 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestContext.completed(TransactionalProtocolOperationHandler.java:475)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at javax.security.auth.Subject.doAs(Subject.java:360)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
> 2015-09-23 06:43:40,186 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.security.AccessController.doPrivileged(Native Method)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at java.lang.Thread.run(Thread.java:745)
> 2015-09-23 06:43:40,187 ERROR [stderr] (Host Controller Service Threads - 82) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> What happens here is the slave HC executing the 'block' op has sent a prepare message to the master, and then when the commit has not come back yet the test driver triggers a cancel on the slave. At this point the thread running the 'block' op returns and tries to send the final result to the master. But it fails because the prepare logic has nulled out the responseChannel field, and the commit message has not arrived yet to restore a new one.
> If assertions weren't enabled, the result would be an NPE when the null responseChannel is used.
> I don't see any reason for null out the responseChannel.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 21:04:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 28 Sep 2015 21:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5422) SSO is not destroyed after
 session timeout period of <distributable/> app.
In-Reply-To: <JIRA.12585651.1442925504000@Atlassian.JIRA>
References: <JIRA.12585651.1442925504000@Atlassian.JIRA>
	<JIRA.12585651.1442925504000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585651.1442925504000.20116.1443488640909@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved UNDERTOW-547 to WFLY-5422:
-----------------------------------------------

              Project: WildFly  (was: Undertow)
                  Key: WFLY-5422  (was: UNDERTOW-547)
          Component/s: Clustering
                       Security
                           (was: Security)
    Affects Version/s: 10.0.0.CR2
                           (was: 1.3.0.CR1)


> SSO is not destroyed after session timeout period of <distributable/> app.
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5422
>                 URL: https://issues.jboss.org/browse/WFLY-5422
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Security
>    Affects Versions: 10.0.0.CR2
>            Reporter: Martin Choma
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> Using <distributable/> application cause SSO doesnt destroy after session timeout period. Base on [1], there is still active session, what is probably cause that SSO is not destroyed.
> Setting similar in EAP6 requires user to login after session timeout period.
> Setting priority to critical because of regression with security impacts.
> [1]
> [standalone at localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
>     "outcome" => "success",
>     "result" => 0
> }
> [2]
> [standalone at localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
>     "outcome" => "success",
>     "result" => 1
> }



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 21:57:00 2015
From: issues at jboss.org (Stefano Picozzi (JIRA))
Date: Mon, 28 Sep 2015 21:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-929) kie-server POST fails with
 No resource method found for POST, return 405 with Allow header
In-Reply-To: <JIRA.12586343.1443491809000@Atlassian.JIRA>
References: <JIRA.12586343.1443491809000@Atlassian.JIRA>
	<JIRA.12586343.1443491809664@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586343.1443491809000.20131.1443491820343@Atlassian.JIRA>

Stefano Picozzi created DROOLS-929:
--------------------------------------

             Summary: kie-server POST fails with No resource method found for POST, return 405 with Allow header
                 Key: DROOLS-929
                 URL: https://issues.jboss.org/browse/DROOLS-929
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 6.3.0.Final
            Reporter: Stefano Picozzi
            Assignee: Edson Tirelli
            Priority: Blocker


Testing the kie-server 6.3.0.FINAL build. I did this by pulling down the jboss/kie-server-showcase docker image and replacing the deployments directory with the kie-server.war for the 6.3.0.FINAL release. My tests showed that the REST API works for GET request for inspecting the decision server, works for PUT requests for creating a container but fails when trying to POST facts against the container. Error returned is as per wildfly log fragment below:

...
01:45:48,333 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "kie-server.war" (runtime-name : "kie-server.war")
01:45:48,354 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
01:45:48,354 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
01:45:48,355 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 11713ms - Started 407 of 458 services (105 services are lazy, passive or on-demand)
01:46:42,788 WARN  [org.kie.scanner.embedder.MavenSettings] (default task-4) Environment variable M2_HOME is not set
01:46:43,310 INFO  [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
01:46:46,462 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (default task-4) KieModule was added: ZipKieModule[releaseId=com.redhat.demos:weightwatchers:1.0,file=/opt/jboss/.m2/repository/com/redhat/demos/weightwatchers/1.0/weightwatchers-1.0.jar]
01:46:46,699 INFO  [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
01:46:47,010 INFO  [org.kie.server.services.impl.KieServerImpl] (default task-4) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
01:47:12,411 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-6) failed to execute: javax.ws.rs.NotAllowedException: No resource method found for POST, return 405 with Allow header
	at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:375) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
	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.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_85]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_85]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 22:22:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Mon, 28 Sep 2015 22:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5408) Upgrade Narayana to
	5.2.5.Final
In-Reply-To: <JIRA.12586111.1443177663000@Atlassian.JIRA>
References: <JIRA.12586111.1443177663000@Atlassian.JIRA>
	<JIRA.12586111.1443177663000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586111.1443177663000.20137.1443493320123@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amos Feng closed WFLY-5408.
---------------------------
    Resolution: Done


> Upgrade Narayana to 5.2.5.Final
> -------------------------------
>
>                 Key: WFLY-5408
>                 URL: https://issues.jboss.org/browse/WFLY-5408
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Sep 28 22:25:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Mon, 28 Sep 2015 22:25:00 -0400 (EDT)
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.20142.1443493500198@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113057#comment-13113057 ] 

Amos Feng commented on WFLY-5100:
---------------------------------

Hi Ondra,

The narayana version has upgrade to 5.2.5.Final. I check on my machine that it works now. can you confirm that the issue resolved ?

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Mon Sep 28 22:46:01 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 28 Sep 2015 22:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5422) SSO is not destroyed after
 session timeout period of <distributable/> app.
In-Reply-To: <JIRA.12585651.1442925504000@Atlassian.JIRA>
References: <JIRA.12585651.1442925504000@Atlassian.JIRA>
	<JIRA.12585651.1442925504000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585651.1442925504000.20159.1443494761099@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-5422:
------------------------------------

    Steps to Reproduce: 

1. 2 same FORM authenticated based app. Session timeout set to 1 min. Application marked <distributalble/> in web.xml
2. SSO switched on in undertow subsystem in standalone.xml using <single-sign-on path="/" />
3. Access first application - login/password requested as expected. Login succesfull.
4. I can access second deployed application as well. - SSO works as expected.
5. Wait > 1 min

6a. Non-<distributalble/> application
Accessing first and second application requires login
Active session count= 0. [1]
6b. <distributalble/> application
Accessing first and second application doesnt require login
Active session count= 1. [2]


  was:


1. 2 same FORM authenticated based app. Session timeout set to 1 min. Application marked <distributalble/> in web.xml
2. SSO switched on in undertow subsystem in standalone.xml using <single-sign-on path="/" />
3. Access first application - login/password requested as expected. Login succesfull.
4. I can access second deployed application as well. - SSO works as expected.
5. Wait > 1 min

6a. Non-<distributalble/> application
Accessing first and second application requires login
Active session count= 0. [1]
6b. <distributalble/> application
Accessing first and second application doesnt require login
Active session count= 1. [2]


              Assignee: Paul Ferraro  (was: Stuart Douglas)


The root cause if this is that the clustering subsystem does not implement the Undertow SessionManager contract correctly. In particular on timeout it just directly invokes the servlet HttpSessionListener implementations, but ignores any Undertow SessionListener implementations that are registered with DistributableSessionManager. As the SSO impl uses these listeners the SSO session never expires.

> SSO is not destroyed after session timeout period of <distributable/> app.
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5422
>                 URL: https://issues.jboss.org/browse/WFLY-5422
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Security
>    Affects Versions: 10.0.0.CR2
>            Reporter: Martin Choma
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> Using <distributable/> application cause SSO doesnt destroy after session timeout period. Base on [1], there is still active session, what is probably cause that SSO is not destroyed.
> Setting similar in EAP6 requires user to login after session timeout period.
> Setting priority to critical because of regression with security impacts.
> [1]
> [standalone at localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
>     "outcome" => "success",
>     "result" => 0
> }
> [2]
> [standalone at localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
>     "outcome" => "success",
>     "result" => 1
> }



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 01:30:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Sep 2015 01:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5416) Unhandled exceptions from
 custom JASPI modules should cause the HTTP status code to be set as an
 error (500, 400, etc)
In-Reply-To: <JIRA.12584738.1442003550000@Atlassian.JIRA>
References: <JIRA.12584738.1442003550000@Atlassian.JIRA>
	<JIRA.12584738.1442003550000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584738.1442003550000.20195.1443504600362@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113074#comment-13113074 ] 

Stuart Douglas commented on WFLY-5416:
--------------------------------------

This looks good to me

> Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc)
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5416
>                 URL: https://issues.jboss.org/browse/WFLY-5416
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Derek Horton
>            Assignee: Stuart Douglas
>
> If a custom JASPI auth module throws an exception, Wildfly/Undertow (the JASPI authenticator) ignores it and returns a 200.  The web page that was requested does not get displayed.  A blank page and a HTTP 200 are returned.
> Should a 40x or a 500 be returned instead?  Or is it the responsibility of the custom JASPI auth module to set the status correctly?
> It seems like the container would need to be careful and not overwrite a status code that the JASPI module had explicitly set.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 02:14:00 2015
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Tue, 29 Sep 2015 02:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5423) Some tests don't remove
	modules properly
In-Reply-To: <JIRA.12586347.1443507189000@Atlassian.JIRA>
References: <JIRA.12586347.1443507189000@Atlassian.JIRA>
	<JIRA.12586347.1443507189470@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586347.1443507189000.20209.1443507240049@Atlassian.JIRA>

Jan Tymel created WFLY-5423:
-------------------------------

             Summary: Some tests don't remove modules properly
                 Key: WFLY-5423
                 URL: https://issues.jboss.org/browse/WFLY-5423
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 10.0.0.CR2
            Reporter: Jan Tymel


Some test cases (e.g. org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase) don't remove their test modules properly. If the jboss.dist property is used and such a test is run, there will remain redundant folders in JBOSS_DIST/modules.

E.g. if the ExternalTagLibTestCase is executed, the folder "test" will remain in "modules" folder of JBOSS_DIST.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 03:21:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Sep 2015 03:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery
 operations are missing from MDB deployment in domain mode
In-Reply-To: <JIRA.12586289.1443444537000@Atlassian.JIRA>
References: <JIRA.12586289.1443444537000@Atlassian.JIRA>
	<JIRA.12586289.1443444537000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586289.1443444537000.20359.1443511260334@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113082#comment-13113082 ] 

RH Bugzilla Integration commented on WFLY-5418:
-----------------------------------------------

Dmitrii Tikhomirov <dtikhomi at redhat.com> changed the Status of [bug 1266913|https://bugzilla.redhat.com/show_bug.cgi?id=1266913] from NEW to ASSIGNED

> start-delivery/stop-delivery operations are missing from MDB deployment in domain mode
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5418
>                 URL: https://issues.jboss.org/browse/WFLY-5418
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: JBoss AS7 7.2.0.Final
>         Environment: JBoss EAP 6.4.3
>            Reporter: Tom Ross
>            Assignee: Jeff Mesnil
>
> It is possible to start/stop delivery of messages to MDB in standalone mode using operations
> start-delivery() and stop-delivery() on MDB deployment. 
> Those operations are missing from MDB deployment in domain mode



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 05:27:00 2015
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Tue, 29 Sep 2015 05:27:00 -0400 (EDT)
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.20754.1443518820295@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak reassigned WFLY-5400:
------------------------------------

    Assignee: ANGELA ROBERTSON  (was: Deon Ballard)


> 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
>         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
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 05:43:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 29 Sep 2015 05:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery
 operations descriptions are missing from MDB deployment in domain mode
In-Reply-To: <JIRA.12586289.1443444537000@Atlassian.JIRA>
References: <JIRA.12586289.1443444537000@Atlassian.JIRA>
	<JIRA.12586289.1443444537000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586289.1443444537000.20803.1443519780137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5418:
------------------------------
    Summary: start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode  (was: start-delivery/stop-delivery operations are missing from MDB deployment in domain mode)


> start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5418
>                 URL: https://issues.jboss.org/browse/WFLY-5418
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: JBoss AS7 7.2.0.Final
>         Environment: JBoss EAP 6.4.3
>            Reporter: Tom Ross
>            Assignee: Jeff Mesnil
>
> It is possible to start/stop delivery of messages to MDB in standalone mode using operations
> start-delivery() and stop-delivery() on MDB deployment. 
> Those operations are missing from MDB deployment in domain mode



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 05:44:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 29 Sep 2015 05:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery
 operations descriptions are missing from MDB deployment in domain mode
In-Reply-To: <JIRA.12586289.1443444537000@Atlassian.JIRA>
References: <JIRA.12586289.1443444537000@Atlassian.JIRA>
	<JIRA.12586289.1443444537000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586289.1443444537000.20807.1443519840133@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5418:
------------------------------
    Description: 
It is possible to start/stop delivery of messages to MDB in standalone mode using operations
start-delivery() and stop-delivery() on MDB deployment. 

Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected).

  was:
It is possible to start/stop delivery of messages to MDB in standalone mode using operations
start-delivery() and stop-delivery() on MDB deployment. 

Those operations are missing from MDB deployment in domain mode



> start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5418
>                 URL: https://issues.jboss.org/browse/WFLY-5418
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: JBoss AS7 7.2.0.Final
>         Environment: JBoss EAP 6.4.3
>            Reporter: Tom Ross
>            Assignee: Jeff Mesnil
>
> It is possible to start/stop delivery of messages to MDB in standalone mode using operations
> start-delivery() and stop-delivery() on MDB deployment. 
> Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 05:49:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 29 Sep 2015 05:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5424) Upgrade to Artemis 1.1.1
In-Reply-To: <JIRA.12586379.1443520100000@Atlassian.JIRA>
References: <JIRA.12586379.1443520100000@Atlassian.JIRA>
	<JIRA.12586379.1443520100930@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586379.1443520100000.20834.1443520140135@Atlassian.JIRA>

Jeff Mesnil created WFLY-5424:
---------------------------------

             Summary: Upgrade to Artemis 1.1.1
                 Key: WFLY-5424
                 URL: https://issues.jboss.org/browse/WFLY-5424
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Critical
             Fix For: 10.0.0.Final






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 06:05:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 29 Sep 2015 06:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.20889.1443521100704@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113157#comment-13113157 ] 

Kabir Khan commented on WFCORE-832:
-----------------------------------

I have made changes to https://github.com/kabir/wildfly-core/commits/WFCORE-832 so the output is now
{code}
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {"[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"*\")]" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => true},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "deploy" => {"execute" => true},
                        "list-add" => {"execute" => true},
                        "map-put" => {"execute" => true},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => true},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => true}
                    },
                    "address" => [
                        ("server-group" => "main-server-group"),
                        ("deployment" => "*")
                    ]
                }}
            }
        }
    }]
}
{code}
I am currently running tests locally to make sure I have not broken anything else. It would be good to get some feedback on this before going through the problem of writing proper tests.

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 06:06:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 29 Sep 2015 06:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.20900.1443521160536@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113157#comment-13113157 ] 

Kabir Khan edited comment on WFCORE-832 at 9/29/15 6:05 AM:
------------------------------------------------------------

I have made changes to https://github.com/kabir/wildfly-core/commits/WFCORE-832 so the output is now
{code}
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {"[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"*\")]" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => true},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "deploy" => {"execute" => true},
                        "list-add" => {"execute" => true},
                        "map-put" => {"execute" => true},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => true},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => true}
                    },
                    "address" => [
                        ("server-group" => "main-server-group"),
                        ("deployment" => "*")
                    ]
                }}
            }
        }
    }]
}
{code}
I am currently running tests locally to make sure I have not broken anything else. It would be good to get some feedback on this before going to the effort of writing proper tests.


was (Author: kabirkhan):
I have made changes to https://github.com/kabir/wildfly-core/commits/WFCORE-832 so the output is now
{code}
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {"[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"*\")]" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => true},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "deploy" => {"execute" => true},
                        "list-add" => {"execute" => true},
                        "map-put" => {"execute" => true},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => true},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => true}
                    },
                    "address" => [
                        ("server-group" => "main-server-group"),
                        ("deployment" => "*")
                    ]
                }}
            }
        }
    }]
}
{code}
I am currently running tests locally to make sure I have not broken anything else. It would be good to get some feedback on this before going through the problem of writing proper tests.

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 06:13:00 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 29 Sep 2015 06:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.20942.1443521580568@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-5374:
------------------------------
    Affects Version/s: 10.0.0.CR2


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1, 10.0.0.CR2
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 06:13:01 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 29 Sep 2015 06:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.20950.1443521581107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-5374:
---------------------------------

    Assignee: Clebert Suconic  (was: Jeff Mesnil)


> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1, 10.0.0.CR2
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Clebert Suconic
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 06:15:02 2015
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 29 Sep 2015 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.20961.1443521702719@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113161#comment-13113161 ] 

Jeff Mesnil commented on WFLY-5374:
-----------------------------------

WildFly 10CR2 uses the vanilla Artemis 1.1.0. The error is still happening with it so it looks like there is a real issue with its native lib on IBM JDK 8.

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1, 10.0.0.CR2
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Clebert Suconic
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 06:46:01 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 29 Sep 2015 06:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.21208.1443523561146@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113157#comment-13113157 ] 

Kabir Khan edited comment on WFCORE-832 at 9/29/15 6:45 AM:
------------------------------------------------------------

I have made changes to https://github.com/kabir/wildfly-core/commits/WFCORE-832 so the output is now
{code}
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {"[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"*\")]" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => true},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "deploy" => {"execute" => true},
                        "list-add" => {"execute" => true},
                        "map-put" => {"execute" => true},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => true},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => true}
                    },
                    "address" => [
                        ("server-group" => "main-server-group"),
                        ("deployment" => "*")
                    ]
                }}
            }
        }
    }]
}
{code}
-I am currently running tests locally to make sure I have not broken anything else.- +The existing core tests pass+
It would be good to get some feedback on this before going to the effort of writing proper tests.


was (Author: kabirkhan):
I have made changes to https://github.com/kabir/wildfly-core/commits/WFCORE-832 so the output is now
{code}
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {"[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"*\")]" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => true},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "deploy" => {"execute" => true},
                        "list-add" => {"execute" => true},
                        "map-put" => {"execute" => true},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => true},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => true}
                    },
                    "address" => [
                        ("server-group" => "main-server-group"),
                        ("deployment" => "*")
                    ]
                }}
            }
        }
    }]
}
{code}
I am currently running tests locally to make sure I have not broken anything else. It would be good to get some feedback on this before going to the effort of writing proper tests.

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 06:50:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Sep 2015 06:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5402) Bump the schema and model
 version for the EJB subsystem
In-Reply-To: <JIRA.12585960.1443098907000@Atlassian.JIRA>
References: <JIRA.12585960.1443098907000@Atlassian.JIRA>
	<JIRA.12585960.1443098907000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585960.1443098907000.21221.1443523800317@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-5402:
-----------------------------------
    Labels: affects_elytron  (was: )


> Bump the schema and model version for the EJB subsystem
> -------------------------------------------------------
>
>                 Key: WFLY-5402
>                 URL: https://issues.jboss.org/browse/WFLY-5402
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 08:02:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Sep 2015 08:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5402) Bump the schema and model
 version for the EJB subsystem
In-Reply-To: <JIRA.12585960.1443098907000@Atlassian.JIRA>
References: <JIRA.12585960.1443098907000@Atlassian.JIRA>
	<JIRA.12585960.1443098907000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585960.1443098907000.21538.1443528120413@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113241#comment-13113241 ] 

Darran Lofthouse commented on WFLY-5402:
----------------------------------------

Commits for this are in the following branch: -
  https://github.com/darranl/wildfly/tree/WFLY-5402

> Bump the schema and model version for the EJB subsystem
> -------------------------------------------------------
>
>                 Key: WFLY-5402
>                 URL: https://issues.jboss.org/browse/WFLY-5402
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 08:16:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Sep 2015 08:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-920) The web.xml of the toolkit
 needs to specify both SPNEGO and Form authentication.
In-Reply-To: <JIRA.12586412.1443528922000@Atlassian.JIRA>
References: <JIRA.12586412.1443528922000@Atlassian.JIRA>
	<JIRA.12586412.1443528922508@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586412.1443528922000.21598.1443528961823@Atlassian.JIRA>

Darran Lofthouse created SECURITY-920:
-----------------------------------------

             Summary: The web.xml of the toolkit needs to specify both SPNEGO and Form authentication.
                 Key: SECURITY-920
                 URL: https://issues.jboss.org/browse/SECURITY-920
             Project: PicketBox 
          Issue Type: Bug
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_3_0_0_Final






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 08:34:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Sep 2015 08:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-84) Jasper using wrong
 ProtectionDomain for compiled JSP
In-Reply-To: <JIRA.12486586.1362598770000@Atlassian.JIRA>
References: <JIRA.12486586.1362598770000@Atlassian.JIRA>
	<JIRA.12486586.1362598770000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486586.1362598770000.21703.1443530040630@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-84:
----------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075100, https://bugzilla.redhat.com/show_bug.cgi?id=1075083, https://bugzilla.redhat.com/show_bug.cgi?id=1267240  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1075100, https://bugzilla.redhat.com/show_bug.cgi?id=1075083)


> Jasper using wrong ProtectionDomain for compiled JSP
> ----------------------------------------------------
>
>                 Key: WFLY-84
>                 URL: https://issues.jboss.org/browse/WFLY-84
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 9.0.0.Beta1
>
>
> Compiled JSPs loaded via JasperLoader appear to be using a different ProtectionDomain than the rest of the WAR deployment.  I think it should probably be using a PD which contains the permissions from the deployment's ClassLoader, and probably the CodeSource from the deployment unit from which the JSP file originated.  This will ensure that permissions set via deployment descriptor and/or the management model will take proper effect.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 08:34:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Sep 2015 08:34:00 -0400 (EDT)
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.21702.1443530040569@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-4864:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1075083, https://bugzilla.redhat.com/show_bug.cgi?id=1267240  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1075083)


> 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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 29 09:04:01 2015
From: issues at jboss.org (Dominik Pospisil (JIRA))
Date: Tue, 29 Sep 2015 09:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5180) InfinispanResourceRefTestCase
 causes NameNotFoundException with security manager
In-Reply-To: <JIRA.12582304.1440412830000@Atlassian.JIRA>
References: <JIRA.12582304.1440412830000@Atlassian.JIRA>
	<JIRA.12582304.1440412830000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582304.1440412830000.21908.1443531841017@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112185#comment-13112185 ] 

Dominik Pospisil edited comment on WFLY-5180 at 9/29/15 9:03 AM:
-----------------------------------------------------------------

The reason of the failure is that the org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanBean is starting a cache in @PostConstruct:

this.cache = this.container.getCache();

If I change the InfinispanBean so that the cache is injected via the web.xml the way the container is than the issue is gone.

The question is do we support starting caches from user code? If yes, it needs to be executed in a priviledged code (at least part of).



was (Author: dpospisil):
The reason of the failure is that the org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanBean is creating a new cache in @PostConstruct:

this.cache = this.container.getCache();

If I change the InfinispanBean so that the cache is injected via the web.xml the way the container is the issue is gone.

The question is do we support creating caches from user code? If yes, it needs to be executed in a priviledged code (at least part of).

> InfinispanResourceRefTestCase causes NameNotFoundException with security manager
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5180
>                 URL: https://issues.jboss.org/browse/WFLY-5180
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Paul Ferraro
>
> *Description of problem:*
> InfinispanResourceRefTestCase causes NameNotFoundException with security manager.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./build.sh -DskipTests -DallTests -Dts.noSmoke
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=InfinispanResourceRefTestCase
> *Actual results:*
> {noformat}
> javax.naming.NameNotFoundException: infinispan
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	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: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.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase.test(InfinispanResourceRefTestCase.java:64)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 29 09:20:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Sep 2015 09:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-294) Formal definition of credential
	names
In-Reply-To: <JIRA.12586427.1443532786000@Atlassian.JIRA>
References: <JIRA.12586427.1443532786000@Atlassian.JIRA>
	<JIRA.12586427.1443532786017@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586427.1443532786000.21976.1443532800574@Atlassian.JIRA>

Darran Lofthouse created ELY-294:
------------------------------------

             Summary: Formal definition of credential names
                 Key: ELY-294
                 URL: https://issues.jboss.org/browse/ELY-294
             Project: WildFly Elytron
          Issue Type: Task
          Components: API / SPI
            Reporter: Darran Lofthouse
             Fix For: 1.1.0.Alpha1


ELY-282 switches the realm APIs so that credentials are queried based on names - these names at the very least form a part of our default API so we need to ensure they are defined somewhere.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 09:23:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Sep 2015 09:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-295) Custom CredentialMapper
In-Reply-To: <JIRA.12586428.1443532925000@Atlassian.JIRA>
References: <JIRA.12586428.1443532925000@Atlassian.JIRA>
	<JIRA.12586428.1443532925429@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586428.1443532925000.21997.1443532980130@Atlassian.JIRA>

Darran Lofthouse created ELY-295:
------------------------------------

             Summary: Custom CredentialMapper
                 Key: ELY-295
                 URL: https://issues.jboss.org/browse/ELY-295
             Project: WildFly Elytron
          Issue Type: Task
          Components: Passwords
            Reporter: Darran Lofthouse
             Fix For: 1.1.0.Alpha1


We will need to review if this is actually required - however with credentials now being query-able by String we may want to support overriding the mappings used by the CredentialMapper either for custom mechanisms or custom realms.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 10:48:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Tue, 29 Sep 2015 10:48:00 -0400 (EDT)
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.22441.1443538080118@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113362#comment-13113362 ] 

Ond?ej Chaloupka commented on WFLY-5100:
----------------------------------------

Hi Amos,

I've done a quick check and it seems working for me. Thank you for the fix.

I have just a small question here. Directory of transaction object store is named {{standalone/data/tx-object-store/HornetqObjectStore/}}. Is this intended? Maybe it should be renamed to {{JournalObjectStore}} but it's rather a cosmetic issue.

> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 29 10:50:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 29 Sep 2015 10:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.22450.1443538200318@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113365#comment-13113365 ] 

Brian Stansberry commented on WFCORE-832:
-----------------------------------------

The basic format looks like what I expect if there's something about the server group that is different: there's an exception entry for server-group=main-server-group/deployment=*.

Are the contents of that exception entry correct given the roles involved? I'm just asking; I have no idea.

I'm curious what it looks like if main-server-group actually has a couple deployments. Intuitively I would expect two or 3 exception entries:

1) server-group=main-server-group/deployment=one 
2) server-group=main-server-group/deployment=two 
3) PERHAPS: server-group=main-server-group/deployment=* 

I might be wrong though; I'm a bit unclear about what drives the "exceptions". Is there one for every actual *resource* that has different perms? Or is it for some sort of "address pattern" kind of thing? The server-group=main-server-group/deployment=* address isn't an actual resource address, nor is it the address under which a resource definition is registered (that's server-group=*/deployment=*). It's kind of a mix of an actual resource address element (server-group=m-s-g) and the address under which a child def is registered (deployment=*).

It seems the exception has to be some sort of "address pattern" thing; otherwise there is no sensible result for the request you posted.

In that case, it seems logical that if there actually were deployment=one and deployment=two present, the result would still be the single exception entry you posted, for server-group=main-server-group/deployment=*. There is no need entries for server-group=main-server-group/deployment=one|two, as those are just concrete instances of the server-group=main-server-group/deployment=* address pattern.

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 10:52:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 29 Sep 2015 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.22471.1443538320646@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113365#comment-13113365 ] 

Brian Stansberry edited comment on WFCORE-832 at 9/29/15 10:51 AM:
-------------------------------------------------------------------

Edited to replace char '*' with 'x' to avoid JIRA formatting issues.

The basic format looks like what I expect if there's something about the server group that is different: there's an exception entry for server-group=main-server-group/deployment=x.

Are the contents of that exception entry correct given the roles involved? I'm just asking; I have no idea.

I'm curious what it looks like if main-server-group actually has a couple deployments. Intuitively I would expect two or 3 exception entries:

1) server-group=main-server-group/deployment=one 
2) server-group=main-server-group/deployment=two 
3) PERHAPS: server-group=main-server-group/deployment=x 

I might be wrong though; I'm a bit unclear about what drives the "exceptions". Is there one for every actual *resource* that has different perms? Or is it for some sort of "address pattern" kind of thing? The server-group=main-server-group/deployment=x address isn't an actual resource address, nor is it the address under which a resource definition is registered (that's server-group=x/deployment=x). It's kind of a mix of an actual resource address element (server-group=m-s-g) and the address under which a child def is registered (deployment=x).

It seems the exception has to be some sort of "address pattern" thing; otherwise there is no sensible result for the request you posted.

In that case, it seems logical that if there actually were deployment=one and deployment=two present, the result would still be the single exception entry you posted, for server-group=main-server-group/deployment=x. There is no need entries for server-group=main-server-group/deployment=one|two, as those are just concrete instances of the server-group=main-server-group/deployment=x address pattern.


was (Author: brian.stansberry):
The basic format looks like what I expect if there's something about the server group that is different: there's an exception entry for server-group=main-server-group/deployment=*.

Are the contents of that exception entry correct given the roles involved? I'm just asking; I have no idea.

I'm curious what it looks like if main-server-group actually has a couple deployments. Intuitively I would expect two or 3 exception entries:

1) server-group=main-server-group/deployment=one 
2) server-group=main-server-group/deployment=two 
3) PERHAPS: server-group=main-server-group/deployment=* 

I might be wrong though; I'm a bit unclear about what drives the "exceptions". Is there one for every actual *resource* that has different perms? Or is it for some sort of "address pattern" kind of thing? The server-group=main-server-group/deployment=* address isn't an actual resource address, nor is it the address under which a resource definition is registered (that's server-group=*/deployment=*). It's kind of a mix of an actual resource address element (server-group=m-s-g) and the address under which a child def is registered (deployment=*).

It seems the exception has to be some sort of "address pattern" thing; otherwise there is no sensible result for the request you posted.

In that case, it seems logical that if there actually were deployment=one and deployment=two present, the result would still be the single exception entry you posted, for server-group=main-server-group/deployment=*. There is no need entries for server-group=main-server-group/deployment=one|two, as those are just concrete instances of the server-group=main-server-group/deployment=* address pattern.

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 10:59:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Sep 2015 10:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-930) ClassCastException after
 segment split during incremental compilation
In-Reply-To: <JIRA.12586469.1443538703000@Atlassian.JIRA>
References: <JIRA.12586469.1443538703000@Atlassian.JIRA>
	<JIRA.12586469.1443538703657@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586469.1443538703000.22491.1443538740222@Atlassian.JIRA>

Mario Fusco created DROOLS-930:
----------------------------------

             Summary: ClassCastException after segment split during incremental compilation
                 Key: DROOLS-930
                 URL: https://issues.jboss.org/browse/DROOLS-930
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


A segment split during an incremental compilation as in the following test case 

{code}
    @Test
    public void testSegmentSplitOnIncrementalCompilation() throws Exception {
        String drl =
                "import " + Person.class.getCanonicalName() + "\n" +
                "rule R1 when\n" +
                "  $s : String()" +
                "  Person( name == $s ) \n" +
                "then\n" +
                "  System.out.println(\"Triggered: R1\");\n" +
                "end\n" +
                "rule R2 when\n" +
                "  $s : String()" +
                "  Person( name == $s ) \n" +
                "then\n" +
                "  System.out.println(\"Triggered: R2\");\n" +
                "end\n" +
                "rule R3 when\n" +
                "  $s : String()" +
                "  Person( name != $s ) \n" +
                "then\n" +
                "  System.out.println(\"Triggered: R3\");\n" +
                "end\n";

        KieServices ks = KieServices.Factory.get();

        ReleaseId releaseId1 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.1");
        KieModule km = createAndDeployJar(ks, releaseId1);

        KieContainer kc = ks.newKieContainer(km.getReleaseId());
        KieSession ksession = kc.newKieSession();

        kc.updateToVersion(releaseId1);
        ksession.insert(new Person("John", 26));
        ksession.insert( "John" );
        ksession.fireAllRules();

        ReleaseId releaseId2 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.2");
        km = createAndDeployJar(ks, releaseId2, drl);

        kc.updateToVersion(releaseId2);
        ksession.fireAllRules();
    }
{code}

may cause the following ClassCastException during the subsequent network evaluation

{code}
java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:99)
	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
	at org.drools.compiler.integrationtests.IncrementalCompilationTest.testSegmentSplit(IncrementalCompilationTest.java:2001)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 11:10:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Sep 2015 11:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-930) ClassCastException after
 segment split during incremental compilation
In-Reply-To: <JIRA.12586469.1443538703000@Atlassian.JIRA>
References: <JIRA.12586469.1443538703000@Atlassian.JIRA>
	<JIRA.12586469.1443538703000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586469.1443538703000.22571.1443539400158@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco closed DROOLS-930.
------------------------------
    Fix Version/s: 6.4.x
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/acd6d0fb1

> ClassCastException after segment split during incremental compilation
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-930
>                 URL: https://issues.jboss.org/browse/DROOLS-930
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.4.x
>
>
> A segment split during an incremental compilation as in the following test case 
> {code}
>     @Test
>     public void testSegmentSplitOnIncrementalCompilation() throws Exception {
>         String drl =
>                 "import " + Person.class.getCanonicalName() + "\n" +
>                 "rule R1 when\n" +
>                 "  $s : String()" +
>                 "  Person( name == $s ) \n" +
>                 "then\n" +
>                 "  System.out.println(\"Triggered: R1\");\n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "  $s : String()" +
>                 "  Person( name == $s ) \n" +
>                 "then\n" +
>                 "  System.out.println(\"Triggered: R2\");\n" +
>                 "end\n" +
>                 "rule R3 when\n" +
>                 "  $s : String()" +
>                 "  Person( name != $s ) \n" +
>                 "then\n" +
>                 "  System.out.println(\"Triggered: R3\");\n" +
>                 "end\n";
>         KieServices ks = KieServices.Factory.get();
>         ReleaseId releaseId1 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.1");
>         KieModule km = createAndDeployJar(ks, releaseId1);
>         KieContainer kc = ks.newKieContainer(km.getReleaseId());
>         KieSession ksession = kc.newKieSession();
>         kc.updateToVersion(releaseId1);
>         ksession.insert(new Person("John", 26));
>         ksession.insert( "John" );
>         ksession.fireAllRules();
>         ReleaseId releaseId2 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.2");
>         km = createAndDeployJar(ks, releaseId2, drl);
>         kc.updateToVersion(releaseId2);
>         ksession.fireAllRules();
>     }
> {code}
> may cause the following ClassCastException during the subsequent network evaluation
> {code}
> java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:99)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> 	at org.drools.compiler.integrationtests.IncrementalCompilationTest.testSegmentSplit(IncrementalCompilationTest.java:2001)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 11:47:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 29 Sep 2015 11:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-929) kie-server POST fails with
 No resource method found for POST, return 405 with Allow header
In-Reply-To: <JIRA.12586343.1443491809000@Atlassian.JIRA>
References: <JIRA.12586343.1443491809000@Atlassian.JIRA>
	<JIRA.12586343.1443491809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586343.1443491809000.22781.1443541620128@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113397#comment-13113397 ] 

Edson Tirelli commented on DROOLS-929:
--------------------------------------

Stefano, we had to change the REST URI for the post slightly in order to support other containers (WLS).

The POST URI is:

server/containers/instances/{id}

Instead of the old:

server/containers/{id}

We are updating the docs to reflect this. 

> kie-server POST fails with No resource method found for POST, return 405 with Allow header
> ------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-929
>                 URL: https://issues.jboss.org/browse/DROOLS-929
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.Final
>            Reporter: Stefano Picozzi
>            Assignee: Edson Tirelli
>            Priority: Blocker
>
> Testing the kie-server 6.3.0.FINAL build. I did this by pulling down the jboss/kie-server-showcase docker image and replacing the deployments directory with the kie-server.war for the 6.3.0.FINAL release. My tests showed that the REST API works for GET request for inspecting the decision server, works for PUT requests for creating a container but fails when trying to POST facts against the container. Error returned is as per wildfly log fragment below:
> ...
> 01:45:48,333 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "kie-server.war" (runtime-name : "kie-server.war")
> 01:45:48,354 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 01:45:48,354 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 01:45:48,355 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 11713ms - Started 407 of 458 services (105 services are lazy, passive or on-demand)
> 01:46:42,788 WARN  [org.kie.scanner.embedder.MavenSettings] (default task-4) Environment variable M2_HOME is not set
> 01:46:43,310 INFO  [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:46,462 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (default task-4) KieModule was added: ZipKieModule[releaseId=com.redhat.demos:weightwatchers:1.0,file=/opt/jboss/.m2/repository/com/redhat/demos/weightwatchers/1.0/weightwatchers-1.0.jar]
> 01:46:46,699 INFO  [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:47,010 INFO  [org.kie.server.services.impl.KieServerImpl] (default task-4) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 01:47:12,411 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-6) failed to execute: javax.ws.rs.NotAllowedException: No resource method found for POST, return 405 with Allow header
> 	at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:375) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	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.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_85]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_85]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 11:48:00 2015
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 29 Sep 2015 11:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-929) kie-server POST fails with
 No resource method found for POST, return 405 with Allow header
In-Reply-To: <JIRA.12586343.1443491809000@Atlassian.JIRA>
References: <JIRA.12586343.1443491809000@Atlassian.JIRA>
	<JIRA.12586343.1443491809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586343.1443491809000.22792.1443541680393@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed DROOLS-929.
--------------------------------
    Resolution: Rejected


If this is still a problem, feel free to reopen this ticket.

> kie-server POST fails with No resource method found for POST, return 405 with Allow header
> ------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-929
>                 URL: https://issues.jboss.org/browse/DROOLS-929
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.Final
>            Reporter: Stefano Picozzi
>            Assignee: Edson Tirelli
>            Priority: Blocker
>
> Testing the kie-server 6.3.0.FINAL build. I did this by pulling down the jboss/kie-server-showcase docker image and replacing the deployments directory with the kie-server.war for the 6.3.0.FINAL release. My tests showed that the REST API works for GET request for inspecting the decision server, works for PUT requests for creating a container but fails when trying to POST facts against the container. Error returned is as per wildfly log fragment below:
> ...
> 01:45:48,333 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "kie-server.war" (runtime-name : "kie-server.war")
> 01:45:48,354 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 01:45:48,354 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 01:45:48,355 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 11713ms - Started 407 of 458 services (105 services are lazy, passive or on-demand)
> 01:46:42,788 WARN  [org.kie.scanner.embedder.MavenSettings] (default task-4) Environment variable M2_HOME is not set
> 01:46:43,310 INFO  [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:46,462 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (default task-4) KieModule was added: ZipKieModule[releaseId=com.redhat.demos:weightwatchers:1.0,file=/opt/jboss/.m2/repository/com/redhat/demos/weightwatchers/1.0/weightwatchers-1.0.jar]
> 01:46:46,699 INFO  [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:47,010 INFO  [org.kie.server.services.impl.KieServerImpl] (default task-4) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 01:47:12,411 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-6) failed to execute: javax.ws.rs.NotAllowedException: No resource method found for POST, return 405 with Allow header
> 	at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:375) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	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.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [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:1145) [rt.jar:1.7.0_85]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_85]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:00:01 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Tue, 29 Sep 2015 12:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1019) History browsing in CLI
 (using the up arrow) works strangely
In-Reply-To: <JIRA.12586492.1443542390000@Atlassian.JIRA>
References: <JIRA.12586492.1443542390000@Atlassian.JIRA>
	<JIRA.12586492.1443542390757@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586492.1443542390000.22832.1443542401412@Atlassian.JIRA>

Ladislav Thon created WFCORE-1019:
-------------------------------------

             Summary: History browsing in CLI (using the up arrow) works strangely
                 Key: WFCORE-1019
                 URL: https://issues.jboss.org/browse/WFCORE-1019
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Ladislav Thon
            Assignee: Alexey Loubyansky


I tend to rely on history browsing in the CLI a lot, but it got broken in EAP 7.0.0.DR10 (I'd guess that the cause is the AESH upgrade). Let's see:

{code}
rm ~/.jboss-cli-history # let's start with clean slate
./jboss-eap-7.0/bin/standalone.sh
# the following is in second console
./jboss-eap-7.0/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}

OK, that's expected. Repeat the process with EAP 7.0.0.DR10 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:01:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Tue, 29 Sep 2015 12:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1019) History browsing in CLI
 (using the up arrow) works strangely
In-Reply-To: <JIRA.12586492.1443542390000@Atlassian.JIRA>
References: <JIRA.12586492.1443542390000@Atlassian.JIRA>
	<JIRA.12586492.1443542390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586492.1443542390000.22835.1443542460103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFCORE-1019:
----------------------------------
    Affects Version/s: 2.0.0.CR5
                       2.0.0.CR1


> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
>                 Key: WFCORE-1019
>                 URL: https://issues.jboss.org/browse/WFCORE-1019
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1, 2.0.0.CR5
>            Reporter: Ladislav Thon
>            Assignee: Alexey Loubyansky
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in EAP 7.0.0.DR10 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./jboss-eap-7.0/bin/standalone.sh
> # the following is in second console
> ./jboss-eap-7.0/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with EAP 7.0.0.DR10 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:02:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Tue, 29 Sep 2015 12:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1019) History browsing in CLI
 (using the up arrow) works strangely
In-Reply-To: <JIRA.12586492.1443542390000@Atlassian.JIRA>
References: <JIRA.12586492.1443542390000@Atlassian.JIRA>
	<JIRA.12586492.1443542390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586492.1443542390000.22842.1443542520327@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFCORE-1019:
----------------------------------
    Description: 
I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:

{code}
rm ~/.jboss-cli-history # let's start with clean slate
./wildfly-10.0.0.Beta2/bin/standalone.sh
# the following is in second console
./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}

OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.

  was:
I tend to rely on history browsing in the CLI a lot, but it got broken in EAP 7.0.0.DR10 (I'd guess that the cause is the AESH upgrade). Let's see:

{code}
rm ~/.jboss-cli-history # let's start with clean slate
./jboss-eap-7.0/bin/standalone.sh
# the following is in second console
./jboss-eap-7.0/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}

OK, that's expected. Repeat the process with EAP 7.0.0.DR10 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.



> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
>                 Key: WFCORE-1019
>                 URL: https://issues.jboss.org/browse/WFCORE-1019
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1, 2.0.0.CR5
>            Reporter: Ladislav Thon
>            Assignee: Alexey Loubyansky
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./wildfly-10.0.0.Beta2/bin/standalone.sh
> # the following is in second console
> ./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:04:00 2015
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Tue, 29 Sep 2015 12:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1019) History browsing in CLI
 (using the up arrow) works strangely
In-Reply-To: <JIRA.12586492.1443542390000@Atlassian.JIRA>
References: <JIRA.12586492.1443542390000@Atlassian.JIRA>
	<JIRA.12586492.1443542390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586492.1443542390000.22849.1443542640147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFCORE-1019:
----------------------------------
    Description: 
I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 / WildFly Core 2.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:

{code}
rm ~/.jboss-cli-history # let's start with clean slate
./wildfly-10.0.0.Beta2/bin/standalone.sh
# the following is in second console
./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}

OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.

  was:
I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:

{code}
rm ~/.jboss-cli-history # let's start with clean slate
./wildfly-10.0.0.Beta2/bin/standalone.sh
# the following is in second console
./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}

OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.



> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
>                 Key: WFCORE-1019
>                 URL: https://issues.jboss.org/browse/WFCORE-1019
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.0.CR1, 2.0.0.CR5
>            Reporter: Ladislav Thon
>            Assignee: Alexey Loubyansky
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 / WildFly Core 2.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./wildfly-10.0.0.Beta2/bin/standalone.sh
> # the following is in second console
> ./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:06:00 2015
From: issues at jboss.org (raj S (JIRA))
Date: Tue, 29 Sep 2015 12:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-931) Drools 4.0.7
In-Reply-To: <JIRA.12586494.1443542724000@Atlassian.JIRA>
References: <JIRA.12586494.1443542724000@Atlassian.JIRA>
	<JIRA.12586494.1443542724349@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586494.1443542724000.22856.1443542760344@Atlassian.JIRA>

raj S created DROOLS-931:
----------------------------

             Summary: Drools 4.0.7
                 Key: DROOLS-931
                 URL: https://issues.jboss.org/browse/DROOLS-931
             Project: Drools
          Issue Type: Bug
         Environment: WAS 6.1(JDK 1.5) & WAS 8.5.5(JDK 1.7)
            Reporter: raj S
            Assignee: Mark Proctor


We have around 10,000+ rules running on a legacy system which is using jdk 1.5. those rules doesn't have salience set for all the rules , but have been tested to work fine with older jdk. 

Now are trying to upgrade the system to later version of JDK, rules execution order seems to be difference ,because they don't have salience set. in the process we have identified that few rules were having coding issues and corrected them. 

Issue: is there a way to grantee the same execution order between the jdk 1.5 & JDK 1.7. we haven't updated the drools version just the JDK. can you please give us some insight in to the natural order of rules execution in drools engine so we can put in a fix outside the engine to ensure the same order. any help is appreciated.






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:14:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Sep 2015 12:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-931) Drools 4.0.7
In-Reply-To: <JIRA.12586494.1443542724000@Atlassian.JIRA>
References: <JIRA.12586494.1443542724000@Atlassian.JIRA>
	<JIRA.12586494.1443542724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586494.1443542724000.22908.1443543240562@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-931:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)


> Drools 4.0.7
> ------------
>
>                 Key: DROOLS-931
>                 URL: https://issues.jboss.org/browse/DROOLS-931
>             Project: Drools
>          Issue Type: Bug
>         Environment: WAS 6.1(JDK 1.5) & WAS 8.5.5(JDK 1.7)
>            Reporter: raj S
>            Assignee: Mario Fusco
>
> We have around 10,000+ rules running on a legacy system which is using jdk 1.5. those rules doesn't have salience set for all the rules , but have been tested to work fine with older jdk. 
> Now are trying to upgrade the system to later version of JDK, rules execution order seems to be difference ,because they don't have salience set. in the process we have identified that few rules were having coding issues and corrected them. 
> Issue: is there a way to grantee the same execution order between the jdk 1.5 & JDK 1.7. we haven't updated the drools version just the JDK. can you please give us some insight in to the natural order of rules execution in drools engine so we can put in a fix outside the engine to ensure the same order. any help is appreciated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:25:00 2015
From: issues at jboss.org (Vsevolod Golovanov (JIRA))
Date: Tue, 29 Sep 2015 12:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5425) http-listener requires
 'https' socket-binding, part 2
In-Reply-To: <JIRA.12586497.1443543850000@Atlassian.JIRA>
References: <JIRA.12586497.1443543850000@Atlassian.JIRA>
	<JIRA.12586497.1443543850102@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586497.1443543850000.22974.1443543900205@Atlassian.JIRA>

Vsevolod Golovanov created WFLY-5425:
----------------------------------------

             Summary: http-listener requires 'https' socket-binding, part 2
                 Key: WFLY-5425
                 URL: https://issues.jboss.org/browse/WFLY-5425
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.2.0.Final
            Reporter: Vsevolod Golovanov
            Assignee: Stuart Douglas


Continuing WFLY-2836.
Is there a way to override {{http-listener}}'s {{redirect-socket}} attribute default value ("https") to be null?
{quote}This is just default value, looking at the downside of not having default value for redirect-socket would be that people would not configure it, which would result in problems when having apps that require secure transport.{quote}
Our app doesn't require secure transport.
{code}redirect-socket=""{code}
results in
{noformat}
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[956,166]
Message: "JBAS014704: '' is an invalid value for parameter redirect-socket. Values must have a minimum length of 1 characters"
{noformat}
This:
{code}redirect-socket="null"{code}
treats it literally:
{noformat}
]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.someapp-http-listener is missing [jboss.binding.null]"]}
{noformat}
So we're forced to have a https socket-binding. Which is not a "just define some binding" problem. It's a "negotiate with customers&sysadmins/document it/provide options to configure it" problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:44:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Sep 2015 12:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-931) Drools 4.0.7
In-Reply-To: <JIRA.12586494.1443542724000@Atlassian.JIRA>
References: <JIRA.12586494.1443542724000@Atlassian.JIRA>
	<JIRA.12586494.1443542724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586494.1443542724000.23045.1443545040186@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco closed DROOLS-931.
------------------------------
    Resolution: Rejected


First of all be advised that Drools 4.x and 5.x is no longer supported. Please open another ticket if you believe there's a related issue on Drools 6.x

What you're saying is that you want determinstic behaviour on arbitrary salience. Unfortunately that is never guaranteed and it can change between JVMs and between Drools versions. With Drools 6.x we partially fixed this ambiguity because rules in the same DRL file have an implicit relative salience (if no explicit salience is given). This means that rules that appear first in the file have an higher salience than the ones that comes later. However we still don't have a similar mechanism for rules in different DRL files so in that case it can go arbitrary again.

> Drools 4.0.7
> ------------
>
>                 Key: DROOLS-931
>                 URL: https://issues.jboss.org/browse/DROOLS-931
>             Project: Drools
>          Issue Type: Bug
>         Environment: WAS 6.1(JDK 1.5) & WAS 8.5.5(JDK 1.7)
>            Reporter: raj S
>            Assignee: Mario Fusco
>
> We have around 10,000+ rules running on a legacy system which is using jdk 1.5. those rules doesn't have salience set for all the rules , but have been tested to work fine with older jdk. 
> Now are trying to upgrade the system to later version of JDK, rules execution order seems to be difference ,because they don't have salience set. in the process we have identified that few rules were having coding issues and corrected them. 
> Issue: is there a way to grantee the same execution order between the jdk 1.5 & JDK 1.7. we haven't updated the drools version just the JDK. can you please give us some insight in to the natural order of rules execution in drools engine so we can put in a fix outside the engine to ensure the same order. any help is appreciated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 12:59:00 2015
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 29 Sep 2015 12:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1001) Starting embedded server
 overwrites standalone/config/logging.properties with a mostly blank config
In-Reply-To: <JIRA.12585689.1442943974000@Atlassian.JIRA>
References: <JIRA.12585689.1442943974000@Atlassian.JIRA>
	<JIRA.12585689.1442943974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585689.1442943974000.23076.1443545940063@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills closed WFCORE-1001.
-----------------------------
    Resolution: Done


> Starting embedded server overwrites standalone/config/logging.properties with a mostly blank config
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1001
>                 URL: https://issues.jboss.org/browse/WFCORE-1001
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 2.0.0.CR6
>
>
> Note the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties
>  $ ./build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/bin/jboss-cli.sh 
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> Check the contents of build/target/wildfly-core-2.0.0.CR4-SNAPSHOT/standalone/configuration/logging.properties, the file is empty.
> Starting standalone will restore the default contents.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 13:44:00 2015
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 29 Sep 2015 13:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1019) History browsing in CLI
 (using the up arrow) works strangely
In-Reply-To: <JIRA.12586492.1443542390000@Atlassian.JIRA>
References: <JIRA.12586492.1443542390000@Atlassian.JIRA>
	<JIRA.12586492.1443542390000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586492.1443542390000.23264.1443548640715@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFCORE-1019:
--------------------------------------
    Issue Type: Enhancement  (was: Bug)


> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
>                 Key: WFCORE-1019
>                 URL: https://issues.jboss.org/browse/WFCORE-1019
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 2.0.0.CR1, 2.0.0.CR5
>            Reporter: Ladislav Thon
>            Assignee: Alexey Loubyansky
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 / WildFly Core 2.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./wildfly-10.0.0.Beta2/bin/standalone.sh
> # the following is in second console
> ./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 13:46:00 2015
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Tue, 29 Sep 2015 13:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4465) Update PicketLink Capabilities
In-Reply-To: <JIRA.12566938.1427325718000@Atlassian.JIRA>
References: <JIRA.12566938.1427325718000@Atlassian.JIRA>
	<JIRA.12566938.1427325718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566938.1427325718000.23274.1443548760054@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-4465:
-----------------------------
    Summary: Update PicketLink Capabilities  (was: Update PicketLink modules for Undertow)


> Update PicketLink Capabilities
> ------------------------------
>
>                 Key: WFLY-4465
>                 URL: https://issues.jboss.org/browse/WFLY-4465
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 10.0.0.CR2
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> Update PicketLink modules in order to support currently capabilities provided in EAP 6 / JBossWeb.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 13:49:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 29 Sep 2015 13:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5426) Data sources other than h2
 cannot be added to domain servers
In-Reply-To: <JIRA.12586509.1443548889000@Atlassian.JIRA>
References: <JIRA.12586509.1443548889000@Atlassian.JIRA>
	<JIRA.12586509.1443548889355@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586509.1443548889000.23282.1443548940315@Atlassian.JIRA>

James Perkins created WFLY-5426:
-----------------------------------

             Summary: Data sources other than h2 cannot be added to domain servers
                 Key: WFLY-5426
                 URL: https://issues.jboss.org/browse/WFLY-5426
             Project: WildFly
          Issue Type: Bug
          Components: JCA
    Affects Versions: 9.0.0.Final
            Reporter: James Perkins
            Assignee: Stefano Maestri
            Priority: Critical
             Fix For: 10.0.0.Final


This seems to work okay with the h2 driver, but adding a postgres driver add operations fail.

The driver is deployed and is on the {{main-server-group}} which defaults to the {{full}} profile.
{code}
[domain at localhost:9990 /] /server-group=main-server-group:read-children-resources(child-type=deployment,recursive=true,include-runtime=true)
{
    "outcome" => "success",
    "result" => {"postgresql-9.4-1201.jdbc41.jar" => {
        "enabled" => true,
        "name" => "postgresql-9.4-1201.jdbc41.jar",
        "runtime-name" => "postgresql-9.4-1201.jdbc41.jar"
    }}
}
{code}

Attempting to add the data source results in the following error:
{code}
[domain at localhost:9990 /] /profile=full/subsystem=datasources/data-source=test-pg:add(driver-name=postgresql-9.4-1201.jdbc41.jar, connection-url=jdbc:postgresql://localhost:test,user-name=user,password=password, jndi-name=java:jboss/datasources/test-pg)
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
    Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
        "server-two" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
    Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}}
    }}}}}},
    "rolled-back" => true,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "failed",
            "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
    Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
            "rolled-back" => true
        }},
        "server-two" => {"response" => {
            "outcome" => "failed",
            "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
    Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
            "rolled-back" => true
        }}
    }}}}
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 13:52:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 29 Sep 2015 13:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5426) Data sources other than h2
 cannot be added to domain servers
In-Reply-To: <JIRA.12586509.1443548889000@Atlassian.JIRA>
References: <JIRA.12586509.1443548889000@Atlassian.JIRA>
	<JIRA.12586509.1443548889000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586509.1443548889000.23299.1443549120281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-5426:
--------------------------------
    Priority: Blocker  (was: Critical)


> Data sources other than h2 cannot be added to domain servers
> ------------------------------------------------------------
>
>                 Key: WFLY-5426
>                 URL: https://issues.jboss.org/browse/WFLY-5426
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 9.0.0.Final
>            Reporter: James Perkins
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>
> This seems to work okay with the h2 driver, but adding a postgres driver add operations fail.
> The driver is deployed and is on the {{main-server-group}} which defaults to the {{full}} profile.
> {code}
> [domain at localhost:9990 /] /server-group=main-server-group:read-children-resources(child-type=deployment,recursive=true,include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {"postgresql-9.4-1201.jdbc41.jar" => {
>         "enabled" => true,
>         "name" => "postgresql-9.4-1201.jdbc41.jar",
>         "runtime-name" => "postgresql-9.4-1201.jdbc41.jar"
>     }}
> }
> {code}
> Attempting to add the data source results in the following error:
> {code}
> [domain at localhost:9990 /] /profile=full/subsystem=datasources/data-source=test-pg:add(driver-name=postgresql-9.4-1201.jdbc41.jar, connection-url=jdbc:postgresql://localhost:test,user-name=user,password=password, jndi-name=java:jboss/datasources/test-pg)
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
>         "server-two" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}}
>     }}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
>             "rolled-back" => true
>         }},
>         "server-two" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
>             "rolled-back" => true
>         }}
>     }}}}
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 13:53:00 2015
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Tue, 29 Sep 2015 13:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4465) Update PicketLink Capabilities
In-Reply-To: <JIRA.12566938.1427325718000@Atlassian.JIRA>
References: <JIRA.12566938.1427325718000@Atlassian.JIRA>
	<JIRA.12566938.1427325718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566938.1427325718000.23304.1443549180055@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-4465:
-----------------------------
    Description: Update PicketLink modules and subsystem in order to support currently capabilities provided in EAP 6 / JBossWeb.  (was: Update PicketLink modules in order to support currently capabilities provided in EAP 6 / JBossWeb.)


> Update PicketLink Capabilities
> ------------------------------
>
>                 Key: WFLY-4465
>                 URL: https://issues.jboss.org/browse/WFLY-4465
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 10.0.0.CR2
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> Update PicketLink modules and subsystem in order to support currently capabilities provided in EAP 6 / JBossWeb.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 14:44:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Sep 2015 14:44:00 -0400 (EDT)
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.23432.1443552240270@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-5340:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1263336, https://bugzilla.redhat.com/show_bug.cgi?id=1267355  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1263336)


> 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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 29 16:36:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 29 Sep 2015 16:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.23726.1443558960546@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113527#comment-13113527 ] 

Kabir Khan commented on WFCORE-832:
-----------------------------------

They are each listed when there are several deployments. The following sequence of CLI commands starts with no deployments:
{code}
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {"[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"*\")]" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => true},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "deploy" => {"execute" => true},
                        "list-add" => {"execute" => true},
                        "map-put" => {"execute" => true},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => true},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => true}
                    },
                    "address" => [
                        ("server-group" => "main-server-group"),
                        ("deployment" => "*")
                    ]
                }}
            }
        }
    }]
}
[domain at localhost:9990 /] deploy ~/temp/Calendar.war
One of --disabled, --all-server-groups or --server-groups is missing.
[domain at localhost:9990 /] deploy ~/temp/Calendar.war --all-server-groups
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {"[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"Calendar.war\")]" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => true
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => true},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "deploy" => {"execute" => true},
                        "list-add" => {"execute" => true},
                        "map-put" => {"execute" => true},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => true},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => true}
                    },
                    "address" => [
                        ("server-group" => "main-server-group"),
                        ("deployment" => "Calendar.war")
                    ]
                }}
            }
        }
    }]
}
[domain at localhost:9990 /] deploy ~/temp/Calendar2.war --all-server-groups
[domain at localhost:9990 /] /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("server-group" => "*"),
            ("deployment" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "notifications" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => false,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => false
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "runtime-name" => {
                            "read" => true,
                            "write" => false
                        }
                    },
                    "operations" => {
                        "read-children-types" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "map-clear" => {"execute" => false},
                        "list-get" => {"execute" => true},
                        "write-attribute" => {"execute" => false},
                        "remove" => {"execute" => false},
                        "deploy" => {"execute" => false},
                        "list-add" => {"execute" => false},
                        "map-put" => {"execute" => false},
                        "read-attribute-group-names" => {"execute" => true},
                        "redeploy" => {"execute" => false},
                        "read-resource-description" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => false},
                        "query" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "map-get" => {"execute" => true},
                        "list-clear" => {"execute" => false},
                        "read-attribute" => {"execute" => true},
                        "map-remove" => {"execute" => false},
                        "read-attribute-group" => {"execute" => true},
                        "undefine-attribute" => {"execute" => false},
                        "read-children-names" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "list-remove" => {"execute" => false},
                        "read-children-resources" => {"execute" => true},
                        "undeploy" => {"execute" => false}
                    }
                },
                "exceptions" => {
                    "[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"Calendar2.war\")]" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "enabled" => {
                                "read" => true,
                                "write" => true
                            },
                            "name" => {
                                "read" => true,
                                "write" => true
                            },
                            "runtime-name" => {
                                "read" => true,
                                "write" => true
                            }
                        },
                        "operations" => {
                            "read-children-types" => {"execute" => true},
                            "whoami" => {"execute" => true},
                            "map-clear" => {"execute" => true},
                            "list-get" => {"execute" => true},
                            "write-attribute" => {"execute" => true},
                            "remove" => {"execute" => true},
                            "deploy" => {"execute" => true},
                            "list-add" => {"execute" => true},
                            "map-put" => {"execute" => true},
                            "read-attribute-group-names" => {"execute" => true},
                            "redeploy" => {"execute" => true},
                            "read-resource-description" => {"execute" => true},
                            "read-resource" => {"execute" => true},
                            "add" => {"execute" => true},
                            "query" => {"execute" => true},
                            "read-operation-description" => {"execute" => true},
                            "map-get" => {"execute" => true},
                            "list-clear" => {"execute" => true},
                            "read-attribute" => {"execute" => true},
                            "map-remove" => {"execute" => true},
                            "read-attribute-group" => {"execute" => true},
                            "undefine-attribute" => {"execute" => true},
                            "read-children-names" => {"execute" => true},
                            "read-operation-names" => {"execute" => true},
                            "list-remove" => {"execute" => true},
                            "read-children-resources" => {"execute" => true},
                            "undeploy" => {"execute" => true}
                        },
                        "address" => [
                            ("server-group" => "main-server-group"),
                            ("deployment" => "Calendar2.war")
                        ]
                    },
                    "[(\"server-group\" => \"main-server-group\"),(\"deployment\" => \"Calendar.war\")]" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "enabled" => {
                                "read" => true,
                                "write" => true
                            },
                            "name" => {
                                "read" => true,
                                "write" => true
                            },
                            "runtime-name" => {
                                "read" => true,
                                "write" => true
                            }
                        },
                        "operations" => {
                            "read-children-types" => {"execute" => true},
                            "whoami" => {"execute" => true},
                            "map-clear" => {"execute" => true},
                            "list-get" => {"execute" => true},
                            "write-attribute" => {"execute" => true},
                            "remove" => {"execute" => true},
                            "deploy" => {"execute" => true},
                            "list-add" => {"execute" => true},
                            "map-put" => {"execute" => true},
                            "read-attribute-group-names" => {"execute" => true},
                            "redeploy" => {"execute" => true},
                            "read-resource-description" => {"execute" => true},
                            "read-resource" => {"execute" => true},
                            "add" => {"execute" => true},
                            "query" => {"execute" => true},
                            "read-operation-description" => {"execute" => true},
                            "map-get" => {"execute" => true},
                            "list-clear" => {"execute" => true},
                            "read-attribute" => {"execute" => true},
                            "map-remove" => {"execute" => true},
                            "read-attribute-group" => {"execute" => true},
                            "undefine-attribute" => {"execute" => true},
                            "read-children-names" => {"execute" => true},
                            "read-operation-names" => {"execute" => true},
                            "list-remove" => {"execute" => true},
                            "read-children-resources" => {"execute" => true},
                            "undeploy" => {"execute" => true}
                        },
                        "address" => [
                            ("server-group" => "main-server-group"),
                            ("deployment" => "Calendar.war")
                        ]
                    }
                }
            }
        }
    }]
}
[domain at localhost:9990 /] 
{code}

The following is a bit half-digested.... While I see what you are saying regarding folding Calendar.war and Calendar2.war together into deployment=x, I am also not sure if that is feasible when there are actual children. The main worry is if we have say 4 deployments, if three of them have the same exception and the fourth not, do we roll 3 of them together as deployment=x, and the last as deployment=unique? Also this could affect other things in other places? At the same time, it seems that things under server-group are slightly special due to the server scoped roles.

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 16:37:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 29 Sep 2015 16:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1020) NPE in GlobalAddressHandlers
In-Reply-To: <JIRA.12586528.1443558990000@Atlassian.JIRA>
References: <JIRA.12586528.1443558990000@Atlassian.JIRA>
	<JIRA.12586528.1443558990508@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586528.1443558990000.23728.1443559020063@Atlassian.JIRA>

Brian Stansberry created WFCORE-1020:
----------------------------------------

             Summary: NPE in GlobalAddressHandlers
                 Key: WFCORE-1020
                 URL: https://issues.jboss.org/browse/WFCORE-1020
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 2.0.0.CR5, 1.0.1.Final, 1.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 2.0.0.CR6


I've seen stack traces like the following pop up in testsuite logs:

{code}
2015-09-29 08:11:50,515 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 88) WFLYCTL0190: Step handler org.jboss.as.controller.operations.global.GlobalOperationHandlers$ModelAddressResolver$4 at b4ea88 for operation {"operation" => "read-resource","address" => [("host" => "slave"),("server" => "main-three")],"operation-headers" => {"caller-type" => "user","access-mechanism" => "NATIVE","domain-uuid" => "5352863e-b467-4d70-b0b1-fa640cc022a1"}} at address [
    ("host" => "slave"),
    ("server" => "main-three")
] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
	at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ModelAddressResolver$4$1.handleResult(GlobalOperationHandlers.java:708)
	at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
	at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
	at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
	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:1336)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:233)
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:360)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
	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}

There's a call to ModelNode.remove("access-control") and then the return value is dereferenced without a null check. The "remove" method may return null.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 16:55:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 29 Sep 2015 16:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-832) Access control exceptions
 missing for non-existent resources
In-Reply-To: <JIRA.12578735.1437478596000@Atlassian.JIRA>
References: <JIRA.12578735.1437478596000@Atlassian.JIRA>
	<JIRA.12578735.1437478596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578735.1437478596000.23767.1443560100162@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113534#comment-13113534 ] 

Brian Stansberry commented on WFCORE-832:
-----------------------------------------

Thanks.

I agree that rolling them up would be both difficult and could lead to other bugs.

I think what you have is ok, so long as there is a clear pattern that always applies and can be documented. Something like:

"If in the exceptions section there is an entry with a wildcard value in an element of its address, this indicates there is resource type definition registered under that exact element, but that there are no actual resource instances of that type. If there are actual resource instances of a type, there will be individual exceptions entries for those resources."

> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
>                 Key: WFCORE-832
>                 URL: https://issues.jboss.org/browse/WFCORE-832
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block: 
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "replace-deployment" => {"execute" => false},
>                         "stop-servers" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => false},
>                         "resume-servers" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => false},
>                         "reload-servers" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => false},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-default-interface" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => true},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "remove" => {"execute" => false},
>                         "list-add" => {"execute" => true},
>                         "map-put" => {"execute" => true},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "resume-servers" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "suspend-servers" => {"execute" => true},
>                         "reload-servers" => {"execute" => true},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => true},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "read-children-names" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true}
>                     },
>                     "address" => [("server-group" => "main-server-group")]
>                 }}
>             }
>         }
>     }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("server-group" => "*"),
>             ("deployment" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
>             "attributes" => undefined,
>             "operations" => undefined,
>             "notifications" => undefined,
>             "children" => {},
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => false,
>                     "attributes" => {
>                         "enabled" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "name" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "runtime-name" => {
>                             "read" => true,
>                             "write" => false
>                         }
>                     },
>                     "operations" => {
>                         "read-children-types" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "map-clear" => {"execute" => false},
>                         "list-get" => {"execute" => true},
>                         "write-attribute" => {"execute" => false},
>                         "remove" => {"execute" => false},
>                         "deploy" => {"execute" => false},
>                         "list-add" => {"execute" => false},
>                         "map-put" => {"execute" => false},
>                         "read-attribute-group-names" => {"execute" => true},
>                         "redeploy" => {"execute" => false},
>                         "read-resource-description" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => false},
>                         "query" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "map-get" => {"execute" => true},
>                         "list-clear" => {"execute" => false},
>                         "read-attribute" => {"execute" => true},
>                         "map-remove" => {"execute" => false},
>                         "read-attribute-group" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => false},
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "list-remove" => {"execute" => false},
>                         "read-children-resources" => {"execute" => true},
>                         "undeploy" => {"execute" => false}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}
> Some notes on the domain: 
> - Built from WildFly 10 master 
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 17:30:00 2015
From: issues at jboss.org (Rich DiCroce (JIRA))
Date: Tue, 29 Sep 2015 17:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1844) Remove shared transport
In-Reply-To: <JIRA.12541935.1401176528000@Atlassian.JIRA>
References: <JIRA.12541935.1401176528000@Atlassian.JIRA>
	<JIRA.12541935.1401176528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541935.1401176528000.23851.1443562200521@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113551#comment-13113551 ] 

Rich DiCroce commented on JGRP-1844:
------------------------------------

I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view.

So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership.

> Remove shared transport
> -----------------------
>
>                 Key: JGRP-1844
>                 URL: https://issues.jboss.org/browse/JGRP-1844
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 17:41:00 2015
From: issues at jboss.org (Rich DiCroce (JIRA))
Date: Tue, 29 Sep 2015 17:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1844) Remove shared transport
In-Reply-To: <JIRA.12541935.1401176528000@Atlassian.JIRA>
References: <JIRA.12541935.1401176528000@Atlassian.JIRA>
	<JIRA.12541935.1401176528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541935.1401176528000.23862.1443562860257@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113551#comment-13113551 ] 

Rich DiCroce edited comment on JGRP-1844 at 9/29/15 5:40 PM:
-------------------------------------------------------------

I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view.

So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership.

EDIT: I was wrong about the address, that is indeed the same on both the fork and the main. I must've been looking at the wrong channels. But the point about the view still stands.


was (Author: rcd):
I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view.

So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership.

> Remove shared transport
> -----------------------
>
>                 Key: JGRP-1844
>                 URL: https://issues.jboss.org/browse/JGRP-1844
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 20:16:01 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Sep 2015 20:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1844) Remove shared transport
In-Reply-To: <JIRA.12541935.1401176528000@Atlassian.JIRA>
References: <JIRA.12541935.1401176528000@Atlassian.JIRA>
	<JIRA.12541935.1401176528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541935.1401176528000.24020.1443572161028@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113578#comment-13113578 ] 

Bela Ban commented on JGRP-1844:
--------------------------------

Why can't you create multiple fork channels ? Each fork channel is independent from the others, while they have the same view and address.
The reason for sharing the views is that I made a big mistake a couple of years ago by introducing "service views" which complicated things and were never quite correct compared to JGroups views (google for jgroups "service view").
Can you clarify your use case above with an example ? I'm pretty dead set on removing the shared transport, unless there's a convincing use case / requirement against it...

> Remove shared transport
> -----------------------
>
>                 Key: JGRP-1844
>                 URL: https://issues.jboss.org/browse/JGRP-1844
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 21:23:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Sep 2015 21:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5425) http-listener requires
 'https' socket-binding, part 2
In-Reply-To: <JIRA.12586497.1443543850000@Atlassian.JIRA>
References: <JIRA.12586497.1443543850000@Atlassian.JIRA>
	<JIRA.12586497.1443543850000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586497.1443543850000.24029.1443576180176@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-5425.
----------------------------------
    Resolution: Out of Date


Fixed by https://github.com/wildfly/wildfly/commit/b20e5fd

> http-listener requires 'https' socket-binding, part 2
> -----------------------------------------------------
>
>                 Key: WFLY-5425
>                 URL: https://issues.jboss.org/browse/WFLY-5425
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Stuart Douglas
>
> Continuing WFLY-2836.
> Is there a way to override {{http-listener}}'s {{redirect-socket}} attribute default value ("https") to be null?
> {quote}This is just default value, looking at the downside of not having default value for redirect-socket would be that people would not configure it, which would result in problems when having apps that require secure transport.{quote}
> Our app doesn't require secure transport.
> {code}redirect-socket=""{code}
> results in
> {noformat}
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[956,166]
> Message: "JBAS014704: '' is an invalid value for parameter redirect-socket. Values must have a minimum length of 1 characters"
> {noformat}
> This:
> {code}redirect-socket="null"{code}
> treats it literally:
> {noformat}
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.someapp-http-listener is missing [jboss.binding.null]"]}
> {noformat}
> So we're forced to have a https socket-binding. Which is not a "just define some binding" problem. It's a "negotiate with customers&sysadmins/document it/provide options to configure it" problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 21:33:01 2015
From: issues at jboss.org (Clebert Suconic (JIRA))
Date: Tue, 29 Sep 2015 21:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.24048.1443576781088@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113584#comment-13113584 ] 

Clebert Suconic commented on WFLY-5374:
---------------------------------------

https://issues.apache.org/jira/browse/ARTEMIS-237

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1, 10.0.0.CR2
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Clebert Suconic
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 21:34:00 2015
From: issues at jboss.org (Clebert Suconic (JIRA))
Date: Tue, 29 Sep 2015 21:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5374) Server start-up fails on IBM
 JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
In-Reply-To: <JIRA.12585469.1442827254000@Atlassian.JIRA>
References: <JIRA.12585469.1442827254000@Atlassian.JIRA>
	<JIRA.12585469.1442827254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585469.1442827254000.24056.1443576840448@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned WFLY-5374:
-------------------------------------

    Assignee: Jeff Mesnil  (was: Clebert Suconic)


Assigning Back to Jeff so he can backport the fix to a fork or something

> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5374
>                 URL: https://issues.jboss.org/browse/WFLY-5374
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.CR1, 10.0.0.CR2
>         Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>         Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version. 
> Console log:
> {code}[hudson at messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
>   JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 05:15:12,726 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO  [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO  [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO  [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO  [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN  [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT  - tr.r14.java_20150625_95081.01
> GC   - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Sep 29 22:42:00 2015
From: issues at jboss.org (Amos Feng (JIRA))
Date: Tue, 29 Sep 2015 22:42:00 -0400 (EDT)
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.24081.1443580920212@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amos Feng resolved WFLY-5100.
-----------------------------
    Resolution: Done


> 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: Ond?ej Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>         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
(v6.4.11#64026)


From issues at jboss.org  Tue Sep 29 22:52:00 2015
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Sep 2015 22:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5388) Intermittent
 java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided
 undertow, resteasy, and jackson
In-Reply-To: <JIRA.12585747.1443000917000@Atlassian.JIRA>
References: <JIRA.12585747.1443000917000@Atlassian.JIRA>
	<JIRA.12585747.1443000917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585747.1443000917000.24086.1443581520274@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113591#comment-13113591 ] 

Stuart Douglas commented on WFLY-5388:
--------------------------------------

I have no idea why but chrome seems to be requesting /optaconf-webapp/rest/conference twice, then cancelling the second one which results in the IOException. I am changing this to a RESTeasy issue. SynchronousDispatcher should not be logging IOExceptions at this level.

> Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5388
>                 URL: https://issues.jboss.org/browse/WFLY-5388
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST, Web (Undertow)
>    Affects Versions: 8.2.1.Final, 9.0.1.Final, 10.0.0.CR1
>            Reporter: Matyas Danter
>            Assignee: Stuart Douglas
>
> When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .
> The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 03:33:00 2015
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=)
Date: Wed, 30 Sep 2015 03:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5427) If used journal object store
 (AMQ Artemis journal) directory is named HornetqObjectStore
In-Reply-To: <JIRA.12586546.1443598366000@Atlassian.JIRA>
References: <JIRA.12586546.1443598366000@Atlassian.JIRA>
	<JIRA.12586546.1443598366590@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586546.1443598366000.24301.1443598380240@Atlassian.JIRA>

Ond?ej Chaloupka created WFLY-5427:
--------------------------------------

             Summary: If used journal object store (AMQ Artemis journal) directory is named HornetqObjectStore
                 Key: WFLY-5427
                 URL: https://issues.jboss.org/browse/WFLY-5427
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
    Affects Versions: 10.0.0.CR2
            Reporter: Ond?ej Chaloupka
            Assignee: Amos Feng
            Priority: Minor


Directory of transaction object store is named {{standalone/data/tx-object-store/HornetqObjectStore}}. The WFLY 10 does not use HornetQ object store but it uses ActiveMQ Artemis object store. That's same for the Transaction subsystem.

The journal dirctory should be renamed to {{JournalObjectStore}} or something similar.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 03:33:00 2015
From: issues at jboss.org (Stefano Picozzi (JIRA))
Date: Wed, 30 Sep 2015 03:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-932) kie-server POST fails with
 org.kie.server.api.marshalling.MarshallingException: Can't marshall input
 object:
In-Reply-To: <JIRA.12586547.1443598368000@Atlassian.JIRA>
References: <JIRA.12586547.1443598368000@Atlassian.JIRA>
	<JIRA.12586547.1443598368211@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586547.1443598368000.24304.1443598380994@Atlassian.JIRA>

Stefano Picozzi created DROOLS-932:
--------------------------------------

             Summary: kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: 
                 Key: DROOLS-932
                 URL: https://issues.jboss.org/browse/DROOLS-932
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 6.3.0.Final
         Environment: kie-server 6.3.0.FINAL with JBoss EAP 6.4.0 or Widfly 8.1.0.FINAL
            Reporter: Stefano Picozzi
            Assignee: Edson Tirelli
            Priority: Blocker


The GET and PUT APIs work OK, e.g. to GET KIE-SERVER details or to PUT a new container.
However a POST to e.g. send some facts to test actual rule reasoning fails as per this log snippet:

07:24:27,998 INFO  [org.kie.server.services.impl.KieServerImpl] (http-/0.0.0.0:8080-1) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
07:24:45,028 ERROR [org.kie.server.services.impl.KieContainerCommandServiceImpl] (http-/0.0.0.0:8080-1) Error calling container 'watch': org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: org.drools.core.runtime.impl.ExecutionResultImpl at 3c402d4b
	at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:187) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
	at org.kie.server.services.impl.KieContainerCommandServiceImpl.callContainer(KieContainerCommandServiceImpl.java:114) [kie-server-services-common-6.3.0.Final.jar:6.3.0.Final]
	at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:73) [kie-server-rest-drools-6.3.0.Final.jar:6.3.0.Final]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
Caused by: javax.xml.bind.MarshalException
 - with linked exception:
[com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.]
	at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251) [jaxb-impl-2.2.11.jar:2.2.11]
	at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95) [jboss-jaxb-api_2.2_spec-1.0.4.Final-redhat-3.jar:1.0.4.Final-redhat-3]
	at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:185) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
	... 32 more
Caused by: com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
	at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.serializeBody(ArrayBeanInfoImpl.java:142) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) [jaxb-impl-2.2.11.jar:2.2.11]
	... 35 more
Caused by: javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:582) [jaxb-impl-2.2.11.jar:2.2.11]
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) [jaxb-impl-2.2.11.jar:2.2.11]
	... 46 more





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 03:59:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 30 Sep 2015 03:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-930) ClassCastException after
 segment split during incremental compilation
In-Reply-To: <JIRA.12586469.1443538703000@Atlassian.JIRA>
References: <JIRA.12586469.1443538703000@Atlassian.JIRA>
	<JIRA.12586469.1443538703000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586469.1443538703000.24363.1443599940483@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113621#comment-13113621 ] 

Mario Fusco commented on DROOLS-930:
------------------------------------

This further commit is not strictly necessary for the fix but recommended to make sure that segment position is always set during segment creation https://github.com/droolsjbpm/drools/commit/efb85633b

> ClassCastException after segment split during incremental compilation
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-930
>                 URL: https://issues.jboss.org/browse/DROOLS-930
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.4.x
>
>
> A segment split during an incremental compilation as in the following test case 
> {code}
>     @Test
>     public void testSegmentSplitOnIncrementalCompilation() throws Exception {
>         String drl =
>                 "import " + Person.class.getCanonicalName() + "\n" +
>                 "rule R1 when\n" +
>                 "  $s : String()" +
>                 "  Person( name == $s ) \n" +
>                 "then\n" +
>                 "  System.out.println(\"Triggered: R1\");\n" +
>                 "end\n" +
>                 "rule R2 when\n" +
>                 "  $s : String()" +
>                 "  Person( name == $s ) \n" +
>                 "then\n" +
>                 "  System.out.println(\"Triggered: R2\");\n" +
>                 "end\n" +
>                 "rule R3 when\n" +
>                 "  $s : String()" +
>                 "  Person( name != $s ) \n" +
>                 "then\n" +
>                 "  System.out.println(\"Triggered: R3\");\n" +
>                 "end\n";
>         KieServices ks = KieServices.Factory.get();
>         ReleaseId releaseId1 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.1");
>         KieModule km = createAndDeployJar(ks, releaseId1);
>         KieContainer kc = ks.newKieContainer(km.getReleaseId());
>         KieSession ksession = kc.newKieSession();
>         kc.updateToVersion(releaseId1);
>         ksession.insert(new Person("John", 26));
>         ksession.insert( "John" );
>         ksession.fireAllRules();
>         ReleaseId releaseId2 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.2");
>         km = createAndDeployJar(ks, releaseId2, drl);
>         kc.updateToVersion(releaseId2);
>         ksession.fireAllRules();
>     }
> {code}
> may cause the following ClassCastException during the subsequent network evaluation
> {code}
> java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:99)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> 	at org.drools.compiler.integrationtests.IncrementalCompilationTest.testSegmentSplit(IncrementalCompilationTest.java:2001)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 04:04:00 2015
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Wed, 30 Sep 2015 04:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-829) Content repo gc task can
 delete content in mid-upload
In-Reply-To: <JIRA.12578450.1437142209000@Atlassian.JIRA>
References: <JIRA.12578450.1437142209000@Atlassian.JIRA>
	<JIRA.12578450.1437142209000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578450.1437142209000.24387.1443600240224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet closed WFCORE-829.
------------------------------------
    Resolution: Rejected


The reopening is not correct as it is a bad usage of the API and NOT the same issue as the original one.

> Content repo gc task can delete content in mid-upload
> -----------------------------------------------------
>
>                 Key: WFCORE-829
>                 URL: https://issues.jboss.org/browse/WFCORE-829
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.Alpha10
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>
> Description of problem:
> if upload of an application takes more than 5 minutes, it is removed from repository by clean-obsolete-content.
> - start the upload
> [Host Controller] 15:44:05,456 INFO  [org.jboss.as.repository] (HttpManagementService-threads - 1) JBAS014900: Content added at location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> - After 5 minutes, the content is removed:
> [Host Controller] 15:49:32,111 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014903: Content /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64 is obsolete and will be removed
> [Host Controller] 15:49:32,113 INFO  [org.jboss.as.repository] (Host Controller Service Threads - 33) JBAS014901: Content removed from location /opt/jboss-eap-6.4/domain-dc/data/content/90/828120fc51e4b5f5ededbb5981198b4be93e64/content
> The reference for the deployment is added to domain.xml only after the upload is finished. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 04:19:00 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 30 Sep 2015 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5428) Xml files from wildfly don't
 end with "new line character"
In-Reply-To: <JIRA.12586556.1443601016000@Atlassian.JIRA>
References: <JIRA.12586556.1443601016000@Atlassian.JIRA>
	<JIRA.12586556.1443601016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586556.1443601016000.24454.1443601140242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? moved JBEAP-1181 to WFLY-5428:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-5428  (was: JBEAP-1181)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Build System
                           (was: Build System)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 10.0.0.CR2
                           (was: 7.0.0.DR11 (Alpha))


> Xml files from wildfly don't end with "new line character"
> ----------------------------------------------------------
>
>                 Key: WFLY-5428
>                 URL: https://issues.jboss.org/browse/WFLY-5428
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.0.0.CR2
>            Reporter: Marek Kopeck?
>            Assignee: Paul Gier
>
> *Description of problem:*
> * Some of xml files from *wildfly* don't end with "new line character".
> * Each xml file should end with "new line character", because of posix standard:
> ** http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
> * List of affected files:
> ** ./docs/examples/configs/standalone-gossip-ha.xml
> ** ./docs/examples/configs/standalone-ec2-ha.xml
> ** ./docs/examples/configs/standalone-picketlink.xml
> ** ./docs/examples/configs/standalone-ec2-full-ha.xml
> ** ./docs/examples/configs/standalone-rts.xml
> ** ./docs/examples/configs/standalone-jts.xml
> ** ./docs/examples/configs/standalone-xts.xml
> ** ./docs/examples/configs/standalone-genericjms.xml
> ** ./docs/examples/configs/standalone-gossip-full-ha.xml
> ** ./standalone/configuration/standalone.xml
> ** ./standalone/configuration/standalone-ha.xml
> ** ./standalone/configuration/standalone-full.xml
> ** ./standalone/configuration/standalone-full-ha.xml
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # {noformat}
> for xml in `find -type f | grep xml$`; do
> if [ "`cat -E $xml | tail -n 1 |grep -o '.$'`" != "$" ] ; then
> echo $xml
> fi
> done
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 04:19:00 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 30 Sep 2015 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1021) Xml files from wildfly-core
 don't end with "new line character"
In-Reply-To: <JIRA.12586557.1443601021000@Atlassian.JIRA>
References: <JIRA.12586557.1443601021000@Atlassian.JIRA>
	<JIRA.12586557.1443601021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586557.1443601021000.24460.1443601140488@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? moved JBEAP-1182 to WFCORE-1021:
----------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1021  (was: JBEAP-1182)
             Workflow: GIT Pull Request workflow   (was: CDW v1)
          Component/s: Server
                           (was: Build System)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s: 2.0.0.CR5
                           (was: 7.0.0.DR11 (Alpha))


> Xml files from wildfly-core don't end with "new line character"
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1021
>                 URL: https://issues.jboss.org/browse/WFCORE-1021
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 2.0.0.CR5
>            Reporter: Marek Kopeck?
>            Assignee: Paul Gier
>
> *Description of problem:*
> * Some of xml files from *wildfly-core* don't end with "new line character".
> * Each xml file should end with "new line character", because of posix standard:
> ** http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
> * List of affected files:
> ** ./modules/system/layers/base/org/wildfly/security/elytron/main/module.xml
> ** ./domain/configuration/host.xml
> ** ./domain/configuration/domain.xml
> ** ./domain/configuration/host-slave.xml
> ** ./domain/configuration/host-master.xml
> ** ./standalone/configuration/standalone.xml
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # {noformat}
> for xml in `find -type f | grep xml$`; do
> if [ "`cat -E $xml | tail -n 1 |grep -o '.$'`" != "$" ] ; then
> echo $xml
> fi
> done
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 04:57:00 2015
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Wed, 30 Sep 2015 04:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5429) Update to Hibernate Validator
	5.2.2.Final
In-Reply-To: <JIRA.12586575.1443603394000@Atlassian.JIRA>
References: <JIRA.12586575.1443603394000@Atlassian.JIRA>
	<JIRA.12586575.1443603394493@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586575.1443603394000.24633.1443603420058@Atlassian.JIRA>

Gunnar Morling created WFLY-5429:
------------------------------------

             Summary: Update to Hibernate Validator 5.2.2.Final
                 Key: WFLY-5429
                 URL: https://issues.jboss.org/browse/WFLY-5429
             Project: WildFly
          Issue Type: Component  Upgrade
            Reporter: Gunnar Morling
            Assignee: Gunnar Morling






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 06:52:00 2015
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 30 Sep 2015 06:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5015) RunAs in servlet doesn't work
In-Reply-To: <JIRA.12579470.1438008155000@Atlassian.JIRA>
References: <JIRA.12579470.1438008155000@Atlassian.JIRA>
	<JIRA.12579470.1438008155000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579470.1438008155000.25018.1443610320361@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas reopened WFLY-5015:
--------------------------------


Reopen. See JBEAP-512 for details.

> RunAs in servlet doesn't work
> -----------------------------
>
>                 Key: WFLY-5015
>                 URL: https://issues.jboss.org/browse/WFLY-5015
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security, Web (Undertow)
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Josef Cacek
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> RunAs for servlets doesn't work in Undertow. 
> I have unprotected {{@RunAs}}-annotated servlet which calls protected EJB method. The call should succeed, but it throws {{javax.ejb.EJBAccessException}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 06:59:00 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 30 Sep 2015 06:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5167)
 IIOPNamingInContainer*TestCase can not connect to ORB with security manager
In-Reply-To: <JIRA.12582183.1440163708000@Atlassian.JIRA>
References: <JIRA.12582183.1440163708000@Atlassian.JIRA>
	<JIRA.12582183.1440163708000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582183.1440163708000.25072.1443610740454@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? reopened WFLY-5167:
---------------------------------


org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerTestCase#testStatefulIIOPNamingInvocation fails with this stacktrace:
{noformat}
org.omg.CORBA.UNKNOWN: 
        at com.sun.corba.se.spi.servicecontext.UEInfoServiceContext.<init>(UEInfoServiceContext.java:52)
        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 com.sun.corba.se.spi.servicecontext.ServiceContextData.makeServiceContext(ServiceContextData.java:132)
        at com.sun.corba.se.spi.servicecontext.ServiceContexts.unmarshal(ServiceContexts.java:216)
        at com.sun.corba.se.spi.servicecontext.ServiceContexts.get(ServiceContexts.java:378)
        at com.sun.corba.se.spi.servicecontext.ServiceContexts.get(ServiceContexts.java:366)
        at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:530)
        at com.sun.corba.se.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:222)
        at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:148)
        at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:475)
        at org.jboss.as.ejb3.iiop.stub.DynamicIIOPStub.invoke(DynamicIIOPStub.java:127)
        at interface org.jboss.as.test.integration.ejb.iiop.naming.IIOPStatefulNamingHome_Stub.create(Unknown Source) 
        at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerTestCase.testStatefulIIOPNamingInvocation(IIOPNamingInContainerTestCase.java:60)
{noformat}

> IIOPNamingInContainer*TestCase can not connect to ORB with security manager
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5167
>                 URL: https://issues.jboss.org/browse/WFLY-5167
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.CR1
>            Reporter: Marek Kopeck?
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR2
>
>
> *Description of problem:*
> Two tests can not connect to ORB with security manager. Tests run in "basic-integration-default-full.surefire" execution of basic profile.
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase
> * org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerTestCase
> *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=IIOPNamingInContainerDDNameTestCase,IIOPNamingInContainerTestCase
> *Actual results:*
> {noformat}
> avax.naming.NamingException: WFLYIIOP0031: Cannot connect to ORB
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2200)
> 	at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2221)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:223)
> 	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 org.wildfly.iiop.openjdk.naming.jndi.CNCtx.setOrbAndRootContext(CNCtx.java:353)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingCorbanameUrl(CNCtx.java:335)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initUsingUrl(CNCtx.java:268)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.initOrbAndRootContext(CNCtx.java:233)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtx.<init>(CNCtx.java:99)
> 	at org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory.getInitialContext(CNCtxFactory.java:53)
> 	at org.wildfly.iiop.openjdk.naming.jndi.WrapperInitialContext.lookup(WrapperInitialContext.java:72)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingInContainerDDNameTestCase.testIIOPNamingInvocationWithDDOverride(IIOPNamingInContainerDDNameTestCase.java:55)
> {noformat}
> *Expected results:*
> No errors on output



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 07:39:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 30 Sep 2015 07:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5430) Rename the EJB3 subsystem to
	EJB
In-Reply-To: <JIRA.12586629.1443613121000@Atlassian.JIRA>
References: <JIRA.12586629.1443613121000@Atlassian.JIRA>
	<JIRA.12586629.1443613121291@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586629.1443613121000.25255.1443613140120@Atlassian.JIRA>

David Lloyd created WFLY-5430:
---------------------------------

             Summary: Rename the EJB3 subsystem to EJB
                 Key: WFLY-5430
                 URL: https://issues.jboss.org/browse/WFLY-5430
             Project: WildFly
          Issue Type: Task
          Components: EJB
            Reporter: David Lloyd
            Priority: Minor


I mean, really.

Retain compatibility with all previous configurations, operations, and schema which may use the name "ejb3".

Identify any public APIs under {{org.jboss.as.ejb3}} and ensure they are retained.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 07:58:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 07:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-296) Pass through Digest
 authentication against LDAP
In-Reply-To: <JIRA.12461866.1331904317000@Atlassian.JIRA>
References: <JIRA.12461866.1331904317000@Atlassian.JIRA>
	<JIRA.12461866.1331904317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461866.1331904317000.25375.1443614280702@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-1217 to ELY-296:
--------------------------------------------

          Project: WildFly Elytron  (was: WildFly)
              Key: ELY-296  (was: WFLY-1217)
      Component/s: Realms
                       (was: Domain Management)
                       (was: Security)
    Fix Version/s:     (was: Awaiting Volunteers)


> Pass through Digest authentication against LDAP
> -----------------------------------------------
>
>                 Key: ELY-296
>                 URL: https://issues.jboss.org/browse/ELY-296
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Realms
>            Reporter: Darran Lofthouse
>              Labels: Common_Authentication
>
> It is possible for a client to authenticate against an LDAP server using Digest authentication.
> This task is to make use of this with both our SASL mechanism and HTTP authenticator to provide a pass through check.
> We need AS7-3691 first and then this needs to be implemented in a way that can consistently be used for both SASL and HTTP Digest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:05:00 2015
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 30 Sep 2015 08:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-933) Allow to optionally pass a
 dependency filter when creating KieModuleMetaData
In-Reply-To: <JIRA.12586645.1443614691000@Atlassian.JIRA>
References: <JIRA.12586645.1443614691000@Atlassian.JIRA>
	<JIRA.12586645.1443614691420@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586645.1443614691000.25466.1443614700447@Atlassian.JIRA>

Mario Fusco created DROOLS-933:
----------------------------------

             Summary: Allow to optionally pass a dependency filter when creating KieModuleMetaData
                 Key: DROOLS-933
                 URL: https://issues.jboss.org/browse/DROOLS-933
             Project: Drools
          Issue Type: Feature Request
            Reporter: Mario Fusco
            Assignee: Mario Fusco


When creating the meta data for a given KieModule it is required to optionally filter its dependencies with the following filtering interface:

{code}
public interface DependencyFilter {
    boolean accept(ReleaseId releaseId, String scope);
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:05:00 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 30 Sep 2015 08:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5154) DenyModulePermissionsTestCase,
 GrantModulePermissionsTestCase,
 LimitedModulePermissionsTestCase cannot deploy jar
In-Reply-To: <JIRA.12582101.1440146883000@Atlassian.JIRA>
References: <JIRA.12582101.1440146883000@Atlassian.JIRA>
	<JIRA.12582101.1440146883000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582101.1440146883000.25469.1443614700573@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? reopened WFLY-5154:
---------------------------------


This issue is still valid in wildfly 10.0.0.CR2

> DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5154
>                 URL: https://issues.jboss.org/browse/WFLY-5154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Josef Cacek
>             Fix For: 10.0.0.CR2
>
>
> *Description of problem*
> * org.jboss.as.testsuite.integration.secman.module.DenyModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-deny.jar
> * org.jboss.as.testsuite.integration.secman.module.GrantModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-grant.jar
> * org.jboss.as.testsuite.integration.secman.module.LimitedModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-limited.jar
> *How reproducible*
> * 15%
> * OpenJDK, IBM JDK, Oracle JDK
> * Solaris, Windows, RHEL
>  
> *Expected results*
> No failures in test case.
> *Additional info*
> See for server logs for DenyModulePermissionsTestCase in attachment



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 08:07:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-755) Security Realm Plug-Ins to
 provide their own configuration parsers.
In-Reply-To: <JIRA.12465873.1336473466000@Atlassian.JIRA>
References: <JIRA.12465873.1336473466000@Atlassian.JIRA>
	<JIRA.12465873.1336473466000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465873.1336473466000.25477.1443614820446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-755.
-----------------------------------
    Release Notes Text: Elytron is bringing custom realm definitions which will be replacing the use of plug-ins
         Fix Version/s: 10.0.0.Final
                            (was: Awaiting Volunteers)
              Assignee: Darran Lofthouse
            Resolution: Out of Date


> Security Realm Plug-Ins to provide their own configuration parsers.
> -------------------------------------------------------------------
>
>                 Key: WFLY-755
>                 URL: https://issues.jboss.org/browse/WFLY-755
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.Final
>
>
> Security realm plug-ins are currently configured with name / value pairs - to make plug-ins easier to use by those that did not implement them we should consider allowing a custom XML parser to allow new configuration elements to be defined.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:08:00 2015
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 30 Sep 2015 08:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5426) Data sources other than h2
 cannot be added to domain servers
In-Reply-To: <JIRA.12586509.1443548889000@Atlassian.JIRA>
References: <JIRA.12586509.1443548889000@Atlassian.JIRA>
	<JIRA.12586509.1443548889000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586509.1443548889000.25501.1443614880808@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113715#comment-13113715 ] 

Stefano Maestri commented on WFLY-5426:
---------------------------------------

it's a regression of linked issue for hot deployed driver (not for module deplyed one)

> Data sources other than h2 cannot be added to domain servers
> ------------------------------------------------------------
>
>                 Key: WFLY-5426
>                 URL: https://issues.jboss.org/browse/WFLY-5426
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 9.0.0.Final
>            Reporter: James Perkins
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 10.0.0.Final
>
>
> This seems to work okay with the h2 driver, but adding a postgres driver add operations fail.
> The driver is deployed and is on the {{main-server-group}} which defaults to the {{full}} profile.
> {code}
> [domain at localhost:9990 /] /server-group=main-server-group:read-children-resources(child-type=deployment,recursive=true,include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {"postgresql-9.4-1201.jdbc41.jar" => {
>         "enabled" => true,
>         "name" => "postgresql-9.4-1201.jdbc41.jar",
>         "runtime-name" => "postgresql-9.4-1201.jdbc41.jar"
>     }}
> }
> {code}
> Attempting to add the data source results in the following error:
> {code}
> [domain at localhost:9990 /] /profile=full/subsystem=datasources/data-source=test-pg:add(driver-name=postgresql-9.4-1201.jdbc41.jar, connection-url=jdbc:postgresql://localhost:test,user-name=user,password=password, jndi-name=java:jboss/datasources/test-pg)
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
>         "server-two" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}}
>     }}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
>             "rolled-back" => true
>         }},
>         "server-two" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.data-source.java:jboss/datasources/test-pg" => "org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/test-pg: WFLYJCA0033: Error during the deployment of test-pg
>     Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}},
>             "rolled-back" => true
>         }}
>     }}}}
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:08:01 2015
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 30 Sep 2015 08:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5154) DenyModulePermissionsTestCase,
 GrantModulePermissionsTestCase,
 LimitedModulePermissionsTestCase cannot deploy jar
In-Reply-To: <JIRA.12582101.1440146883000@Atlassian.JIRA>
References: <JIRA.12582101.1440146883000@Atlassian.JIRA>
	<JIRA.12582101.1440146883000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582101.1440146883000.25515.1443614881140@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-5154:
--------------------------------
    Attachment: GrantModulePermissionsTestCase.stacktrace.txt


> DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5154
>                 URL: https://issues.jboss.org/browse/WFLY-5154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Josef Cacek
>             Fix For: 10.0.0.CR2
>
>         Attachments: GrantModulePermissionsTestCase.stacktrace.txt
>
>
> *Description of problem*
> * org.jboss.as.testsuite.integration.secman.module.DenyModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-deny.jar
> * org.jboss.as.testsuite.integration.secman.module.GrantModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-grant.jar
> * org.jboss.as.testsuite.integration.secman.module.LimitedModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-limited.jar
> *How reproducible*
> * 15%
> * OpenJDK, IBM JDK, Oracle JDK
> * Solaris, Windows, RHEL
>  
> *Expected results*
> No failures in test case.
> *Additional info*
> See for server logs for DenyModulePermissionsTestCase in attachment



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 08:09:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-899) spelling mistakes in the
 management security domain should be logged better
In-Reply-To: <JIRA.12488504.1364983549000@Atlassian.JIRA>
References: <JIRA.12488504.1364983549000@Atlassian.JIRA>
	<JIRA.12488504.1364983549000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488504.1364983549000.25533.1443614940790@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-899.
-----------------------------------
    Release Notes Text: 
Marking as out of date as across the application server we are moving to a new capability and requirement model to handle the dependencies between resources.

The error reporting and level of any additional helpful messages to say suggest available alternatives should be a part of the general capabilities / requirements handling.
         Fix Version/s: 10.0.0.Final
            Resolution: Out of Date


> spelling mistakes in the management security domain should be logged better
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-899
>                 URL: https://issues.jboss.org/browse/WFLY-899
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security, Server
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> A spelling mistake in the management security domain prevents the server from starting (good) but the message in the log file is only stating:
> [Host Controller] 08:35:37,672 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> There in fact no previous messages



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:11:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-747) Dynamic Detection of SPNEGO
 auth method and adding of NegotiationAuthenticator
In-Reply-To: <JIRA.12439301.1307616883000@Atlassian.JIRA>
References: <JIRA.12439301.1307616883000@Atlassian.JIRA>
	<JIRA.12439301.1307616883000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12439301.1307616883000.25568.1443615061540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-747.
-----------------------------------
    Fix Version/s: 10.0.0.Final
                       (was: Awaiting Volunteers)
         Assignee: Darran Lofthouse
       Resolution: Duplicate Issue


SPNEGO authentication has been added to WildFly 10 so no further special handling required.

> Dynamic Detection of SPNEGO auth method and adding of NegotiationAuthenticator
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-747
>                 URL: https://issues.jboss.org/browse/WFLY-747
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.Final
>
>
> Previously a mapping for the SPNEGO auth method and the authenticator had to be manually defined, this capability is not present in AS7 however it is suggested that alternatively we can detect the auth method ourselves and dynamically add the valve - this seems cleaner as it potentially allows SPNEGO to be added/removed from a server without manual configuration being required.
> It is suggested to look at the following code for an example where a valve has been added dynamically before: -
>   org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor in the JPA subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:12:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5431) Enable Elytron backed
 security for Undertow handled deployments.
In-Reply-To: <JIRA.12586647.1443615102000@Atlassian.JIRA>
References: <JIRA.12586647.1443615102000@Atlassian.JIRA>
	<JIRA.12586647.1443615102990@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586647.1443615102000.25577.1443615120230@Atlassian.JIRA>

Darran Lofthouse created WFLY-5431:
--------------------------------------

             Summary: Enable Elytron backed security for Undertow handled deployments.
                 Key: WFLY-5431
                 URL: https://issues.jboss.org/browse/WFLY-5431
             Project: WildFly
          Issue Type: Sub-task
          Components: Web (Undertow)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:14:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4872) Add the Elytron subsystem to
 the feature packs
In-Reply-To: <JIRA.12577134.1436206186000@Atlassian.JIRA>
References: <JIRA.12577134.1436206186000@Atlassian.JIRA>
	<JIRA.12577134.1436206186000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577134.1436206186000.25587.1443615240100@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113723#comment-13113723 ] 

Darran Lofthouse commented on WFLY-4872:
----------------------------------------

So far we create custom standalone-elytron.xml, host-elytron.xml and domain-elytron.xml configurations - at some point we will pull these changes into the actual configurations.

> Add the Elytron subsystem to the feature packs
> ----------------------------------------------
>
>                 Key: WFLY-4872
>                 URL: https://issues.jboss.org/browse/WFLY-4872
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Build System
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-297) Implement an account lockout
 mechanism for domain management.
In-Reply-To: <JIRA.12446171.1314976732000@Atlassian.JIRA>
References: <JIRA.12446171.1314976732000@Atlassian.JIRA>
	<JIRA.12446171.1314976732000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446171.1314976732000.25611.1443615480163@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-569 to ELY-297:
-------------------------------------------

          Project: WildFly Elytron  (was: WildFly)
              Key: ELY-297  (was: WFLY-569)
      Component/s: HTTP
                   Realms
                   SASL
                       (was: Domain Management)
                       (was: Security)
    Fix Version/s:     (was: 11.0.0.Alpha1)


> Implement an account lockout mechanism for domain management.
> -------------------------------------------------------------
>
>                 Key: ELY-297
>                 URL: https://issues.jboss.org/browse/ELY-297
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: HTTP, Realms, SASL
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Common_Authentication, Realm_Management, management_security,
>
> One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: -
> - Consider an option to update the remote store if possible.
> - If not cache a backlisted user until an admin unlocks that account
> Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:18:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-297) Account Lockout
In-Reply-To: <JIRA.12446171.1314976732000@Atlassian.JIRA>
References: <JIRA.12446171.1314976732000@Atlassian.JIRA>
	<JIRA.12446171.1314976732000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446171.1314976732000.25614.1443615480236@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-297:
---------------------------------
    Summary: Account Lockout  (was: Implement an account lockout mechanism for domain management.)


> Account Lockout
> ---------------
>
>                 Key: ELY-297
>                 URL: https://issues.jboss.org/browse/ELY-297
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: HTTP, Realms, SASL
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Common_Authentication, Realm_Management, management_security,
>
> One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: -
> - Consider an option to update the remote store if possible.
> - If not cache a backlisted user until an admin unlocks that account
> Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-297) Account Lockout
In-Reply-To: <JIRA.12446171.1314976732000@Atlassian.JIRA>
References: <JIRA.12446171.1314976732000@Atlassian.JIRA>
	<JIRA.12446171.1314976732000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446171.1314976732000.25633.1443615540638@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113726#comment-13113726 ] 

Darran Lofthouse commented on ELY-297:
--------------------------------------

We need to consider some general 'defense' capabilities to support when using Elytron backed authentication.  At the same time we need to ensure those measures don't become an opportunity for denial of service.  Either way moved to Elytron as this is probably the correct place to consider this now.

> Account Lockout
> ---------------
>
>                 Key: ELY-297
>                 URL: https://issues.jboss.org/browse/ELY-297
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: HTTP, Realms, SASL
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Common_Authentication, Realm_Management, management_security,
>
> One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: -
> - Consider an option to update the remote store if possible.
> - If not cache a backlisted user until an admin unlocks that account
> Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:21:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1173) Remote/Local lookup with user
 authentication should work in the same way
In-Reply-To: <JIRA.12470321.1342120758000@Atlassian.JIRA>
References: <JIRA.12470321.1342120758000@Atlassian.JIRA>
	<JIRA.12470321.1342120758000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470321.1342120758000.25661.1443615661008@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-1173.
------------------------------------
    Fix Version/s: 10.0.0.Final
         Assignee: Darran Lofthouse
       Resolution: Out of Date


> Remote/Local lookup with user authentication should work in the same way
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1173
>                 URL: https://issues.jboss.org/browse/WFLY-1173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, Security
>         Environment: Testing on windows
>            Reporter: Fernando Rubbo
>            Assignee: Darran Lofthouse
>              Labels: local_interface, lookup
>             Fix For: 10.0.0.Final
>
>
> I'm opening this issue because nobody was able to answer my question in the discussions section. So, I strongly believe this is an issue of the JBoss 7.
> Let's to the issue: ctx.getCallerPrincipal() should work in the same way, no matter if it was a remote or a local lookup. For more details and an source code example, please see this thread: https://community.jboss.org/thread/202291



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:22:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 30 Sep 2015 08:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679784@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.25666.1443615720333@Atlassian.JIRA>

Kabir Khan created ELY-298:
------------------------------

             Summary: load-from/uri keystore xsd/parser mismatch
                 Key: ELY-298
                 URL: https://issues.jboss.org/browse/ELY-298
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Kabir Khan
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Alpha1


The xsd has
{code}
  <xsd:complexType name="key-store-type">
        <xsd:sequence minOccurs="1" maxOccurs="1">
            <!-- Access source type -->
            <xsd:choice minOccurs="1" maxOccurs="1">
                <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
                <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
                <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
{code}
The parser seems to look for 'uri' rather than 'load-from'




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 08:24:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 08:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-708) Need to configure JAAS for
 host controller in host.xml
In-Reply-To: <JIRA.12527987.1387178413000@Atlassian.JIRA>
References: <JIRA.12527987.1387178413000@Atlassian.JIRA>
	<JIRA.12527987.1387178413000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527987.1387178413000.25678.1443615840278@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-708.
-------------------------------------
    Fix Version/s: 2.0.0.CR6
         Assignee: Darran Lofthouse
       Resolution: Won't Fix


With ongoing changes this is not something we are planning to develop further.

> Need to configure JAAS for host controller in host.xml
> ------------------------------------------------------
>
>                 Key: WFCORE-708
>                 URL: https://issues.jboss.org/browse/WFCORE-708
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Hisanobu Okuda
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR6
>
>
> I want to configure an advanced authentication for host controller as follow:-
> (1) perform authentication against LDAP
> (2) if (1) fails, perform authentication against properties file
> To do this in domain mode, I need to set up a legacy JAAS config file and specify it via java.security.auth.login.config system property. It spoils maintainability and security of EAP6 in terms of:-
> 1. unable to maintain it using jboss-cli.sh
> 2. unable to use the vault feature for it



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:01:02 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 30 Sep 2015 09:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5428) Xml files from wildfly don't
 end with "new line character"
In-Reply-To: <JIRA.12586556.1443601016000@Atlassian.JIRA>
References: <JIRA.12586556.1443601016000@Atlassian.JIRA>
	<JIRA.12586556.1443601016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586556.1443601016000.26015.1443618062068@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-5428:
---------------------------------

    Assignee: Tomaz Cerar  (was: Paul Gier)


> Xml files from wildfly don't end with "new line character"
> ----------------------------------------------------------
>
>                 Key: WFLY-5428
>                 URL: https://issues.jboss.org/browse/WFLY-5428
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.0.0.CR2
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>
> *Description of problem:*
> * Some of xml files from *wildfly* don't end with "new line character".
> * Each xml file should end with "new line character", because of posix standard:
> ** http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
> * List of affected files:
> ** ./docs/examples/configs/standalone-gossip-ha.xml
> ** ./docs/examples/configs/standalone-ec2-ha.xml
> ** ./docs/examples/configs/standalone-picketlink.xml
> ** ./docs/examples/configs/standalone-ec2-full-ha.xml
> ** ./docs/examples/configs/standalone-rts.xml
> ** ./docs/examples/configs/standalone-jts.xml
> ** ./docs/examples/configs/standalone-xts.xml
> ** ./docs/examples/configs/standalone-genericjms.xml
> ** ./docs/examples/configs/standalone-gossip-full-ha.xml
> ** ./standalone/configuration/standalone.xml
> ** ./standalone/configuration/standalone-ha.xml
> ** ./standalone/configuration/standalone-full.xml
> ** ./standalone/configuration/standalone-full-ha.xml
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # {noformat}
> for xml in `find -type f | grep xml$`; do
> if [ "`cat -E $xml | tail -n 1 |grep -o '.$'`" != "$" ] ; then
> echo $xml
> fi
> done
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 09:01:02 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 30 Sep 2015 09:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1021) Xml files from wildfly-core
 don't end with "new line character"
In-Reply-To: <JIRA.12586557.1443601021000@Atlassian.JIRA>
References: <JIRA.12586557.1443601021000@Atlassian.JIRA>
	<JIRA.12586557.1443601021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586557.1443601021000.26021.1443618062221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFCORE-1021:
-----------------------------------

    Assignee: Tomaz Cerar  (was: Paul Gier)


> Xml files from wildfly-core don't end with "new line character"
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1021
>                 URL: https://issues.jboss.org/browse/WFCORE-1021
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 2.0.0.CR5
>            Reporter: Marek Kopeck?
>            Assignee: Tomaz Cerar
>
> *Description of problem:*
> * Some of xml files from *wildfly-core* don't end with "new line character".
> * Each xml file should end with "new line character", because of posix standard:
> ** http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
> * List of affected files:
> ** ./modules/system/layers/base/org/wildfly/security/elytron/main/module.xml
> ** ./domain/configuration/host.xml
> ** ./domain/configuration/domain.xml
> ** ./domain/configuration/host-slave.xml
> ** ./domain/configuration/host-master.xml
> ** ./standalone/configuration/standalone.xml
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # {noformat}
> for xml in `find -type f | grep xml$`; do
> if [ "`cat -E $xml | tail -n 1 |grep -o '.$'`" != "$" ] ; then
> echo $xml
> fi
> done
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 09:08:00 2015
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Wed, 30 Sep 2015 09:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5179) Some tests are unable to init
 arquillian protocol with security manager
In-Reply-To: <JIRA.12582301.1440411788000@Atlassian.JIRA>
References: <JIRA.12582301.1440411788000@Atlassian.JIRA>
	<JIRA.12582301.1440411788000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582301.1440411788000.26089.1443618480230@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113756#comment-13113756 ] 

Gytis Trikleris commented on WFLY-5179:
---------------------------------------

Just to let you know, I'm updating RTS and XTS tests to work with security manager: https://github.com/gytis/jboss-as/commit/6799626bff25cd40fe1f0a68e94b72c1bf1d67e7

I have to push changed to the Narayana code base first. But after that, I'll push test changes to WildFly upstream too.

> Some tests are unable to init arquillian protocol with security manager
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5179
>                 URL: https://issues.jboss.org/browse/WFLY-5179
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Ondrej Kotek
>
> *Description of problem:*
> Some tests are unable to init arquillian protocol with security manager.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testEjbLink
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testLookup
> * org.jboss.as.test.integration.ee.injection.resource.enventry.EnvEntryInjectionTestCase#testEnvEntryInjectionIntoServlet
> * org.jboss.as.test.integration.ejb.security.AuthenticationTestCase
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction
> *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=EjbLocalRefInjectionTestCase
> *Actual results:*
> {noformat}
> java.lang.RuntimeException: Could not init arquillian protocol
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> 	at org.xnio.Xnio.getInstance(Xnio.java:193)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:122)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> 	at org.jboss.as.arquillian.container.ManagementClient.init(ManagementClient.java:140)
> 	at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:177)
> 	at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.performCall(EjbLocalRefInjectionTestCase.java:62)
> 	at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.testEjbLink(EjbLocalRefInjectionTestCase.java:73)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 09:12:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-299) Add getCredentialSupport
 methods that taks the credential type as an argument.
In-Reply-To: <JIRA.12586666.1443618677000@Atlassian.JIRA>
References: <JIRA.12586666.1443618677000@Atlassian.JIRA>
	<JIRA.12586666.1443618677077@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586666.1443618677000.26119.1443618720309@Atlassian.JIRA>

Darran Lofthouse created ELY-299:
------------------------------------

             Summary: Add getCredentialSupport methods that taks the credential type as an argument.
                 Key: ELY-299
                 URL: https://issues.jboss.org/browse/ELY-299
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: API / SPI
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Alpha1


In ELY-282 getCredentialSupport is being switched to check based on credential name, however at the mechanism level there is still a need to know that the correct type can also be obtained as a mechanism is also dependent on the type.

If we add getCredentialSupport(String credentialName, Class<?> credentialType) we can convert the methods that just take credential name to be default methods that call getCredentialSupport(credentialName, Object.class);




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-54) Support for stronger hashes as
 alternatives to MD5
In-Reply-To: <JIRA.12479914.1354008365000@Atlassian.JIRA>
References: <JIRA.12479914.1354008365000@Atlassian.JIRA>
	<JIRA.12479914.1354008365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479914.1354008365000.26162.1443619140415@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-54:
--------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
>                 Key: ELY-54
>                 URL: https://issues.jboss.org/browse/ELY-54
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-95) Password types should generate a
 salt if none is given
In-Reply-To: <JIRA.12554704.1412866108000@Atlassian.JIRA>
References: <JIRA.12554704.1412866108000@Atlassian.JIRA>
	<JIRA.12554704.1412866108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554704.1412866108000.26169.1443619140535@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-95:
--------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Password types should generate a salt if none is given
> ------------------------------------------------------
>
>                 Key: ELY-95
>                 URL: https://issues.jboss.org/browse/ELY-95
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Passwords
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Alpha2
>
>
> Password types such as {{crypt-md5}} should be able to generate a password from a {{ClearPasswordSpec}} by generating a simple random salt.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:19:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-154) Session based DigestCredential
	support
In-Reply-To: <JIRA.12562822.1423567275000@Atlassian.JIRA>
References: <JIRA.12562822.1423567275000@Atlassian.JIRA>
	<JIRA.12562822.1423567275000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562822.1423567275000.26178.1443619140802@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-154:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Session based DigestCredential support
> --------------------------------------
>
>                 Key: ELY-154
>                 URL: https://issues.jboss.org/browse/ELY-154
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>          Components: Passwords
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>
> DigestCredential but where additional information is included such as nonce and cnonce to create a credential applicable to a session.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:20:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-208) Update SASL mechanism testing
 to also be domain backed.
In-Reply-To: <JIRA.12574102.1433532317000@Atlassian.JIRA>
References: <JIRA.12574102.1433532317000@Atlassian.JIRA>
	<JIRA.12574102.1433532317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574102.1433532317000.26182.1443619200612@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-208:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Update SASL mechanism testing to also be domain backed.
> -------------------------------------------------------
>
>                 Key: ELY-208
>                 URL: https://issues.jboss.org/browse/ELY-208
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Testsuite
>            Reporter: Darran Lofthouse
>            Assignee: Kabir Khan
>             Fix For: 1.1.0.Alpha2
>
>
> There may be a little bit more work required before this is possible but we need to ensure SASL mechanisms are also tested using a CallbackHandler they are likely to encounter which will really be the one from ServerAuthenticationContext.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:20:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-232) AuthorizeCallback shall be last
In-Reply-To: <JIRA.12578318.1437070510000@Atlassian.JIRA>
References: <JIRA.12578318.1437070510000@Atlassian.JIRA>
	<JIRA.12578318.1437070510000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578318.1437070510000.26185.1443619200700@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-232:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> AuthorizeCallback shall be last
> -------------------------------
>
>                 Key: ELY-232
>                 URL: https://issues.jboss.org/browse/ELY-232
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Alpha2
>
>
> Go through each SASL server mechanism and ensure that AuthorizeCallback is checked last (after credential/password verification, user name assignment, realm checks, etc.).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:20:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:20:00 -0400 (EDT)
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.26188.1443619200756@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-251:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> 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.1.0.Alpha2
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:20:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-262) The equivalent of wrap and
 unwrap for HTTP authentication mechanisms
In-Reply-To: <JIRA.12580681.1438967809000@Atlassian.JIRA>
References: <JIRA.12580681.1438967809000@Atlassian.JIRA>
	<JIRA.12580681.1438967809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580681.1438967809000.26202.1443619201221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-262:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> The equivalent of wrap and unwrap for HTTP authentication mechanisms
> --------------------------------------------------------------------
>
>                 Key: ELY-262
>                 URL: https://issues.jboss.org/browse/ELY-262
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>          Components: HTTP
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:21:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-268) Review how mechanisms meet
	HttpAuthenticator
In-Reply-To: <JIRA.12581257.1439579134000@Atlassian.JIRA>
References: <JIRA.12581257.1439579134000@Atlassian.JIRA>
	<JIRA.12581257.1439579134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581257.1439579134000.26207.1443619260517@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-268:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Review how mechanisms meet HttpAuthenticator
> --------------------------------------------
>
>                 Key: ELY-268
>                 URL: https://issues.jboss.org/browse/ELY-268
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>
> The current implementation is using a Supplier<List<HttpServerAuthenticationMechanism>> when get is called on this Supplier a ServerAuthenticationContext needs to be created, then all possible mechanisms need to be queried before the list of mechanisms is created.
> The HTTP Authenticator is created per request.  API may be fine but we may need an easier way to provide all the mechanisms.
> Will look at that one later once hot deployment is also considered fully.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:21:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-270) Support separated columns for
 salt and cost when using the PasswordKeyMapper
In-Reply-To: <JIRA.12581274.1439593256000@Atlassian.JIRA>
References: <JIRA.12581274.1439593256000@Atlassian.JIRA>
	<JIRA.12581274.1439593256000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581274.1439593256000.26210.1443619260644@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-270:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Support separated columns for salt and cost when using the PasswordKeyMapper
> ----------------------------------------------------------------------------
>
>                 Key: ELY-270
>                 URL: https://issues.jboss.org/browse/ELY-270
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Realms
>    Affects Versions: 1.0.0.Alpha3
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>             Fix For: 1.1.0.Alpha2
>
>
> Currently, the ```PasswordKeyMapper``` is only supporting BCRYPT passwords if they are stored using the Modular Crypt format.
> Should also be possible to map BCRYPT passwords using separated columns for hash, salt and cost.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:21:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-279) Support CORS
In-Reply-To: <JIRA.12583145.1440770018000@Atlassian.JIRA>
References: <JIRA.12583145.1440770018000@Atlassian.JIRA>
	<JIRA.12583145.1440770018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583145.1440770018000.26213.1443619260718@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-279:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Support CORS
> ------------
>
>                 Key: ELY-279
>                 URL: https://issues.jboss.org/browse/ELY-279
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>
> This is something that can possibly be tied in around the HTTP authentication framework meaning that the control of this can live in the HTTP authentication policy within Elytron rather than at the front end.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:21:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-290) Ensure a sensible default
 timeout on the LDAP connections
In-Reply-To: <JIRA.12584979.1442329906000@Atlassian.JIRA>
References: <JIRA.12584979.1442329906000@Atlassian.JIRA>
	<JIRA.12584979.1442329906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584979.1442329906000.26223.1443619261043@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-290:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Ensure a sensible default timeout on the LDAP connections
> ---------------------------------------------------------
>
>                 Key: ELY-290
>                 URL: https://issues.jboss.org/browse/ELY-290
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Realms
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>
> By long enough I mean long enough to cope with network performance issues but short enough to prevent permanent hangs.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:21:01 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-293) Add file based auth to http
 management interface
In-Reply-To: <JIRA.12487616.1363783129000@Atlassian.JIRA>
References: <JIRA.12487616.1363783129000@Atlassian.JIRA>
	<JIRA.12487616.1363783129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487616.1363783129000.26228.1443619261423@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-293:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> Add file based auth to http management interface
> ------------------------------------------------
>
>                 Key: ELY-293
>                 URL: https://issues.jboss.org/browse/ELY-293
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Max Rydahl Andersen
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>
> usecase: allow clients using http api to use the file based auth so they do not have to rely on the binary protocol and remoting.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:22:00 2015
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Sep 2015 09:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.26242.1443619320554@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-298:
---------------------------------
    Fix Version/s: 1.1.0.Alpha2
                       (was: 1.1.0.Alpha1)


> load-from/uri keystore xsd/parser mismatch
> ------------------------------------------
>
>                 Key: ELY-298
>                 URL: https://issues.jboss.org/browse/ELY-298
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Alpha2
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {code}
> The parser seems to look for 'uri' rather than 'load-from'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:31:00 2015
From: issues at jboss.org (George Zalizko (JIRA))
Date: Wed, 30 Sep 2015 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1966) Specify logger name for
 LogRecord in JDKLogImpl
In-Reply-To: <JIRA.12586670.1443619845000@Atlassian.JIRA>
References: <JIRA.12586670.1443619845000@Atlassian.JIRA>
	<JIRA.12586670.1443619845514@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586670.1443619845000.26299.1443619860241@Atlassian.JIRA>

George Zalizko created JGRP-1966:
------------------------------------

             Summary: Specify logger name for LogRecord in JDKLogImpl
                 Key: JGRP-1966
                 URL: https://issues.jboss.org/browse/JGRP-1966
             Project: JGroups
          Issue Type: Enhancement
    Affects Versions: 3.6.6
            Reporter: George Zalizko
            Assignee: Bela Ban
            Priority: Minor


I use Spring Boot with logback.
For logging I have pattern:
{code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code}

And in console I see: 
{code}
16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN  unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code}

This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger"

Actually I don't know is it done specially or not, but I can't find any comments/solutions for that. 




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 09:58:00 2015
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Wed, 30 Sep 2015 09:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5179) Some tests are unable to init
 arquillian protocol with security manager
In-Reply-To: <JIRA.12582301.1440411788000@Atlassian.JIRA>
References: <JIRA.12582301.1440411788000@Atlassian.JIRA>
	<JIRA.12582301.1440411788000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582301.1440411788000.26434.1443621480396@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108250#comment-13108250 ] 

Ondrej Kotek edited comment on WFLY-5179 at 9/30/15 9:57 AM:
-------------------------------------------------------------

Fixed test cases avoid using ManagementClient when running in non-RunAsClient mode.
EjbLocalRefInjectionTestCase and EnvEntryInjectionTestCase were split -- no permissions needed.
AuthenticationTestCase -and XTS TransactionalTestCase- have new permissions and comments.


was (Author: okotek):
Fixed test cases avoid using ManagementClient when running in non-RunAsClient mode.
EjbLocalRefInjectionTestCase and EnvEntryInjectionTestCase were split -- no permissions needed.
AuthenticationTestCase and XTS TransactionalTestCase have new permissions and comments.

> Some tests are unable to init arquillian protocol with security manager
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5179
>                 URL: https://issues.jboss.org/browse/WFLY-5179
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Ondrej Kotek
>
> *Description of problem:*
> Some tests are unable to init arquillian protocol with security manager.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testEjbLink
> * org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase#testLookup
> * org.jboss.as.test.integration.ee.injection.resource.enventry.EnvEntryInjectionTestCase#testEnvEntryInjectionIntoServlet
> * org.jboss.as.test.integration.ejb.security.AuthenticationTestCase
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction
> * org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction
> *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=EjbLocalRefInjectionTestCase
> *Actual results:*
> {noformat}
> java.lang.RuntimeException: Could not init arquillian protocol
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> 	at org.xnio.Xnio.getInstance(Xnio.java:193)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:122)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> 	at org.jboss.as.arquillian.container.ManagementClient.init(ManagementClient.java:140)
> 	at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:177)
> 	at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.performCall(EjbLocalRefInjectionTestCase.java:62)
> 	at org.jboss.as.test.integration.ee.injection.resource.ejblocalref.EjbLocalRefInjectionTestCase.testEjbLink(EjbLocalRefInjectionTestCase.java:73)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 10:28:00 2015
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 30 Sep 2015 10:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3612) Implement missing
 transformers for new bean validation subsystem
In-Reply-To: <JIRA.12546142.1405043868000@Atlassian.JIRA>
References: <JIRA.12546142.1405043868000@Atlassian.JIRA>
	<JIRA.12546142.1405043868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546142.1405043868000.26585.1443623280157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3612:
-----------------------------------
    Priority: Critical  (was: Blocker)


> Implement missing transformers for new bean validation subsystem
> ----------------------------------------------------------------
>
>                 Key: WFLY-3612
>                 URL: https://issues.jboss.org/browse/WFLY-3612
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, EE
>            Reporter: Brian Stansberry
>            Assignee: Eduardo Martins
>            Priority: Critical
>
> The initial work on WFLY-3551 will be merged without needed transformers, because the transformer support we have won't allow the needed transformation. This JIRA is a reminder to add it once the required work in WFCORE-291 is done.
> From my comment on the PR for the WFLY-3551 work:
> There needs to be a discard of this resource if a legacy slave is involved. The presence of the resource means BV is wanted, and by default the legacy slave will have BV, so if this resource exists, the legacy slave is compatible. The resource just needs to be discarded so the legacy slave doesn't fail when it sees resources/ops for this subsystem it can't understand.
> If this subsystem is omitted in a config with ee, the legacy slave will be out of sync with newer ones running the same profile, because the old ones will have BV and the new ones won't. But
> 1) it's a corner case
> 2) it may not matter anyway in terms of behavior of an app
> 3) the transformer logic we have doesn't allow us to do anything about it anyway.
> Re: that last part, when doing this work double check on skipping that, in case the WFLY-3563 work makes it real easy. Unlikely though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 10:52:00 2015
From: issues at jboss.org (Davide Marchetti (JIRA))
Date: Wed, 30 Sep 2015 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5432) Wildfly SOAP webservice
	causes JVM crash
In-Reply-To: <JIRA.12586700.1443624709000@Atlassian.JIRA>
References: <JIRA.12586700.1443624709000@Atlassian.JIRA>
	<JIRA.12586700.1443624709236@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586700.1443624709000.26722.1443624720174@Atlassian.JIRA>

Davide Marchetti created WFLY-5432:
--------------------------------------

             Summary: Wildfly SOAP webservice causes JVM crash
                 Key: WFLY-5432
                 URL: https://issues.jboss.org/browse/WFLY-5432
             Project: WildFly
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 10.0.0.CR2, 9.0.1.Final
         Environment: Tested on Mac OSX 10.10.2, jdk 1.8.60, wildfly 9.0.1. Final / 10.cr2
Also tested on Centos 6.5, jdk 1.7.51, wildfly 9.0.1. Final
            Reporter: Davide Marchetti
            Assignee: Alessio Soldano
         Attachments: SOAPTest.war

The JVM crashes with either a sigsegv or sigbus error when performing a SOAP load test.
The error printed is:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f5da922afb8, pid=75645, tid=140039627204352
#
# JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_15_01_39-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J  org.apache.cxf.message.ExchangeImpl.get(Ljava/lang/Class;)Ljava/lang/Object;
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
 
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   15:56:03,314 INFO  [stdout] (default task-17) Submitted order request received with transId: <XXXXX>, opId: <SCO>, ...
http://icedtea.classpath.org/bugzilla
#


The webservice does nothing, just a System.out.print("xxxxx").



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 10:54:00 2015
From: issues at jboss.org (Davide Marchetti (JIRA))
Date: Wed, 30 Sep 2015 10:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5432) Wildfly SOAP webservice
	causes JVM crash
In-Reply-To: <JIRA.12586700.1443624709000@Atlassian.JIRA>
References: <JIRA.12586700.1443624709000@Atlassian.JIRA>
	<JIRA.12586700.1443624709000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586700.1443624709000.26737.1443624840503@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Marchetti updated WFLY-5432:
-----------------------------------
    Priority: Blocker  (was: Major)


> Wildfly SOAP webservice causes JVM crash
> ----------------------------------------
>
>                 Key: WFLY-5432
>                 URL: https://issues.jboss.org/browse/WFLY-5432
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 9.0.1.Final, 10.0.0.CR2
>         Environment: Tested on Mac OSX 10.10.2, jdk 1.8.60, wildfly 9.0.1. Final / 10.cr2
> Also tested on Centos 6.5, jdk 1.7.51, wildfly 9.0.1. Final
>            Reporter: Davide Marchetti
>            Assignee: Alessio Soldano
>            Priority: Blocker
>              Labels: crash, jvm, soap, webservice
>         Attachments: SOAPTest.war
>
>
> The JVM crashes with either a sigsegv or sigbus error when performing a SOAP load test.
> The error printed is:
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f5da922afb8, pid=75645, tid=140039627204352
> #
> # JRE version: OpenJDK Runtime Environment (7.0_51-b02) (build 1.7.0_51-mockbuild_2014_01_15_01_39-b00)
> # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # J  org.apache.cxf.message.ExchangeImpl.get(Ljava/lang/Class;)Ljava/lang/Object;
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
>  
> #
> # If you would like to submit a bug report, please include
> # instructions on how to reproduce the bug and visit:
> #   15:56:03,314 INFO  [stdout] (default task-17) Submitted order request received with transId: <XXXXX>, opId: <SCO>, ...
> http://icedtea.classpath.org/bugzilla
> #
> The webservice does nothing, just a System.out.print("xxxxx").



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 11:40:01 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Sep 2015 11:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350000@Atlassian.JIRA>
References: <JIRA.12508815.1382711350000@Atlassian.JIRA>
	<JIRA.12508815.1382711350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350000.26938.1443627601616@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2387:
-------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Scott Marlow
>         Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	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) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 11:41:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 30 Sep 2015 11:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-300) Absence of key-store-credential
	NPEs
In-Reply-To: <JIRA.12586712.1443627620000@Atlassian.JIRA>
References: <JIRA.12586712.1443627620000@Atlassian.JIRA>
	<JIRA.12586712.1443627620102@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586712.1443627620000.26945.1443627660387@Atlassian.JIRA>

Kabir Khan created ELY-300:
------------------------------

             Summary: Absence of key-store-credential NPEs
                 Key: ELY-300
                 URL: https://issues.jboss.org/browse/ELY-300
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Kabir Khan
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Alpha1


Trying to parse
{code}
<authentication-client xmlns="urn:elytron:1.0">
    <key-stores>
        <key-store name="test" type="PasswordFile">
            <file name="keystore/xml-client-keystore-credential-test.keystore"/>
            <!--<key-store-credential key-store-name="test" alias="test-alias"/>-->
        </key-store>
    </key-stores>
</authentication-client>
{code}

I end up with 
{code}
java.lang.NullPointerException
	at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1082)
	at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1067)
	at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$115(ElytronXmlParser.java:709)
	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$4/1929600551.create(Unknown Source)
	at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:47)
	at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:30)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$106(ElytronXmlParser.java:425)
	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$5/1053782781.create(Unknown Source)
	at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$113(ElytronXmlParser.java:474)
	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$6/2012232625.create(Unknown Source)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRulesType$88(ElytronXmlParser.java:242)
	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$7/627150481.create(Unknown Source)
	at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
	at org.wildfly.security.auth.client.XmlClientKeyStoreCredentialTest.testKeystoreCredential(XmlClientKeyStoreCredentialTest.java:110)
{code}

This appears to be because the passwordFactory is only instantiated when parsing the key-store-credential element




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 11:41:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Sep 2015 11:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2858) JPA doesn't parse for
 "urn:jboss:jpa" namespace in jboss-all.xml
In-Reply-To: <JIRA.12531038.1391444897000@Atlassian.JIRA>
References: <JIRA.12531038.1391444897000@Atlassian.JIRA>
	<JIRA.12531038.1391444897000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531038.1391444897000.26949.1443627660516@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2858:
-------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


> JPA doesn't parse for "urn:jboss:jpa" namespace in jboss-all.xml
> ----------------------------------------------------------------
>
>                 Key: WFLY-2858
>                 URL: https://issues.jboss.org/browse/WFLY-2858
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Looks like the parser is only parsing for "http://www.jboss.com/xml/ns/javaee" and never for "urn:jboss:jpa". This makes the schema less useful.
> https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/docs/schema/jboss-jpa_1_0.xsd
> Example file:
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/epcpropagation/shallow/jboss-all.xml



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 11:42:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Sep 2015 11:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2982) refactor two phase
 persistence unit services (PhaseOnePersistenceUnitServiceImpl +
 PersistenceUnitServiceImpl) into one service
In-Reply-To: <JIRA.12532872.1392925405000@Atlassian.JIRA>
References: <JIRA.12532872.1392925405000@Atlassian.JIRA>
	<JIRA.12532872.1392925405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532872.1392925405000.26952.1443627720383@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2982:
-------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


> refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2982
>                 URL: https://issues.jboss.org/browse/WFLY-2982
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> Related feedback from https://github.com/wildfly/wildfly/pull/4722:
> {quote}
> This is asymetrical, so if this service , and phase one are stopped, and then phase 1 is started again, phase 2 will appear started. The side effects seem minor though
> {quote}
> {quote}
> We have a long term goal to somehow verify every service can be stopped and started with the expected effect. Right now many of our services are not restartable which makes potential new features like partial deployment standby hard to achieve. So Im just offering pointers whenever I see lifecycle symmetry issues.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 11:42:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Sep 2015 11:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3853) Cache PersistenceProviders
 within the same deployment
In-Reply-To: <JIRA.12552031.1410554803000@Atlassian.JIRA>
References: <JIRA.12552031.1410554803000@Atlassian.JIRA>
	<JIRA.12552031.1410554803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552031.1410554803000.26959.1443627720571@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-3853:
-------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


> Cache PersistenceProviders within the same deployment
> -----------------------------------------------------
>
>                 Key: WFLY-3853
>                 URL: https://issues.jboss.org/browse/WFLY-3853
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See wildfly-dev ml discussion [http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html] about calls to PersistenceProviderResolver.getPersistenceProviders() should return a cached list.  The cache should be per deployment.  
> We can probably reuse our PersistenceProviderResolverImpl.persistenceProviderPerClassLoader map, just need to be careful that addDeploymentSpecificPersistenceProvider() is called early before any calls to getPersistenceProviders().



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 11:42:00 2015
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Sep 2015 11:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5319) fix
 org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest
 failure
In-Reply-To: <JIRA.12584552.1441887103000@Atlassian.JIRA>
References: <JIRA.12584552.1441887103000@Atlassian.JIRA>
	<JIRA.12584552.1441887103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584552.1441887103000.26962.1443627720661@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-5319:
-------------------------------
    Fix Version/s:     (was: 10.0.0.Final)


> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5319
>                 URL: https://issues.jboss.org/browse/WFLY-5319
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 11:42:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 30 Sep 2015 11:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5425) http-listener requires
 'https' socket-binding, part 2
In-Reply-To: <JIRA.12586497.1443543850000@Atlassian.JIRA>
References: <JIRA.12586497.1443543850000@Atlassian.JIRA>
	<JIRA.12586497.1443543850000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586497.1443543850000.26966.1443627720801@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-5425:
------------------------------
    Fix Version/s: 9.0.0.Beta2


> http-listener requires 'https' socket-binding, part 2
> -----------------------------------------------------
>
>                 Key: WFLY-5425
>                 URL: https://issues.jboss.org/browse/WFLY-5425
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Beta2
>
>
> Continuing WFLY-2836.
> Is there a way to override {{http-listener}}'s {{redirect-socket}} attribute default value ("https") to be null?
> {quote}This is just default value, looking at the downside of not having default value for redirect-socket would be that people would not configure it, which would result in problems when having apps that require secure transport.{quote}
> Our app doesn't require secure transport.
> {code}redirect-socket=""{code}
> results in
> {noformat}
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[956,166]
> Message: "JBAS014704: '' is an invalid value for parameter redirect-socket. Values must have a minimum length of 1 characters"
> {noformat}
> This:
> {code}redirect-socket="null"{code}
> treats it literally:
> {noformat}
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.someapp-http-listener is missing [jboss.binding.null]"]}
> {noformat}
> So we're forced to have a https socket-binding. Which is not a "just define some binding" problem. It's a "negotiate with customers&sysadmins/document it/provide options to configure it" problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 12:12:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 30 Sep 2015 12:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3351) WildFly self-monitoring
 (history storage + REST API + web console plugin)
In-Reply-To: <JIRA.12540683.1399994205000@Atlassian.JIRA>
References: <JIRA.12540683.1399994205000@Atlassian.JIRA>
	<JIRA.12540683.1399994205000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540683.1399994205000.27091.1443629520261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFLY-3351:
-----------------------------------

    Assignee:     (was: James Perkins)


> WildFly self-monitoring (history storage + REST API + web console plugin)
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3351
>                 URL: https://issues.jboss.org/browse/WFLY-3351
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: Ondrej Zizka
>            Priority: Optional
>
> Would be nice if WildFly had it's optional own submodule which would monitor the AS, store the data, and allow it's retrieval later through REST API. Also, the console could have a plugin to read and display these data.
> This was discussed some time ago as one of requirements by different parties - JON, JBDS, end users.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 12:12:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Sep 2015 12:12:00 -0400 (EDT)
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.27094.1443629520391@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113884#comment-13113884 ] 

RH Bugzilla Integration commented on WFLY-5340:
-----------------------------------------------

Bartek Spyrko-Smietanko <bspyrkos at redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from NEW to ASSIGNED

> 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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 12:27:00 2015
From: issues at jboss.org (Rich DiCroce (JIRA))
Date: Wed, 30 Sep 2015 12:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1844) Remove shared transport
In-Reply-To: <JIRA.12541935.1401176528000@Atlassian.JIRA>
References: <JIRA.12541935.1401176528000@Atlassian.JIRA>
	<JIRA.12541935.1401176528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541935.1401176528000.27190.1443630420148@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113900#comment-13113900 ] 

Rich DiCroce commented on JGRP-1844:
------------------------------------

The situation I am in is that two applications share some Infinispan caches, but also have some of their own independent caches. The short explanation is that I have to create three separate cache managers (one shared, one for each application), each of which requires its own JGroups channel. Infinispan assumes that every node in the view is participating in the cache manager, which isn't true for the app-specific cache managers when using a fork channel.

That is arguably more of an Infinispan problem, and I'm going to file some issues in the Infinispan JIRA for those, but I don't know if or when those issues will ever be resolved. Shared transport is a useful workaround in the meantime. I also have my own fork channel that is used by only one of the two applications, and I need to be able to determine a coordinator within that subset of members. JGroups currently doesn't do anything to help with that, so instead of forking the channel that is shared by both applications, I'm forking the app-specific channel.

It would be nice if JGroups did something for applications using fork channels, so the application can easily determine which cluster members are participating in the fork. Alternatively, is it possible to put the FORK protocol lower in the stack, below the GMS protocol? Then forks would have their own separate views. I haven't tried that but I doubt it would work based on what I've read.

> Remove shared transport
> -----------------------
>
>                 Key: JGRP-1844
>                 URL: https://issues.jboss.org/browse/JGRP-1844
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 12:29:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Sep 2015 12:29:00 -0400 (EDT)
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.27202.1443630540418@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113902#comment-13113902 ] 

RH Bugzilla Integration commented on WFLY-5340:
-----------------------------------------------

Bartek Spyrko-Smietanko <bspyrkos at redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from ASSIGNED to POST

> 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
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 12:35:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 30 Sep 2015 12:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5433) CommandDispatcher can throw
 InvalidClassException if command class is not available
In-Reply-To: <JIRA.12586726.1443630867000@Atlassian.JIRA>
References: <JIRA.12586726.1443630867000@Atlassian.JIRA>
	<JIRA.12586726.1443630867226@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586726.1443630867000.27224.1443630900349@Atlassian.JIRA>

Paul Ferraro created WFLY-5433:
----------------------------------

             Summary: CommandDispatcher can throw InvalidClassException if command class is not available
                 Key: WFLY-5433
                 URL: https://issues.jboss.org/browse/WFLY-5433
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.CR2
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


When CommandDispatcher is used by a deployment, the command class might not be available if the deployment is not deployed.  Normally, this is prevented by returning a NoSuchService response if the service is unknown, however, this happens *after* the command is unmarshalled.  This check should happen before we attempt to unmarshall the command, avoiding unnecessary InvalidClassException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 13:04:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 30 Sep 2015 13:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.27405.1443632640390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-5290:
--------------------------------

    Assignee: Kabir Khan  (was: Paul Ferraro)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 13:05:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 30 Sep 2015 13:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.27416.1443632700358@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113923#comment-13113923 ] 

Kabir Khan commented on WFLY-5290:
----------------------------------

[17:58] Kabir Khan: @PaulFerraro For https://issues.jboss.org/browse/WFLY-5290, what should the transport=TRANSPORT alias become?
[17:59] Paul Ferraro: @KabirKhan it becomes transport=*
[18:00] Kabir Khan: @PaulFerraro That can't map properly, it needs to map onto one resource
[18:00] Paul Ferraro: e.g. transport=TRANSPORT,type=UDP becomes transport=UDP
[18:00] Kabir Khan: ok, I see
		in that case I can try to take a look
[18:01] Paul Ferraro: so - it needs more context than just the address
[18:01] Kabir Khan: and let me guess, that is not available at the moment from AliasEntry
[18:01] Paul Ferraro: right

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 13:09:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 30 Sep 2015 13:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5180) InfinispanResourceRefTestCase
 causes NameNotFoundException with security manager
In-Reply-To: <JIRA.12582304.1440412830000@Atlassian.JIRA>
References: <JIRA.12582304.1440412830000@Atlassian.JIRA>
	<JIRA.12582304.1440412830000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582304.1440412830000.27436.1443632940254@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113924#comment-13113924 ] 

Paul Ferraro commented on WFLY-5180:
------------------------------------

I see - internally, we should be using a privileged action during construction of the cache components that require reflection.

> InfinispanResourceRefTestCase causes NameNotFoundException with security manager
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5180
>                 URL: https://issues.jboss.org/browse/WFLY-5180
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Paul Ferraro
>
> *Description of problem:*
> InfinispanResourceRefTestCase causes NameNotFoundException with security manager.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./build.sh -DskipTests -DallTests -Dts.noSmoke
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=InfinispanResourceRefTestCase
> *Actual results:*
> {noformat}
> javax.naming.NameNotFoundException: infinispan
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	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: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.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase.test(InfinispanResourceRefTestCase.java:64)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 13:11:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 30 Sep 2015 13:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1022) AliasEntry needs more
 information than just the PathAddress
In-Reply-To: <JIRA.12586734.1443633055000@Atlassian.JIRA>
References: <JIRA.12586734.1443633055000@Atlassian.JIRA>
	<JIRA.12586734.1443633055466@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586734.1443633055000.27444.1443633060118@Atlassian.JIRA>

Kabir Khan created WFCORE-1022:
----------------------------------

             Summary: AliasEntry needs more information than just the PathAddress
                 Key: WFCORE-1022
                 URL: https://issues.jboss.org/browse/WFCORE-1022
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Kabir Khan
            Priority: Critical
             Fix For: 2.0.0.CR6


As mentioned on https://issues.jboss.org/browse/WFLY-5290

[17:58] Kabir Khan: @PaulFerraro For https://issues.jboss.org/browse/WFLY-5290, what should the transport=TRANSPORT alias become?
[17:59] Paul Ferraro: @KabirKhan it becomes transport=*
[18:00] Kabir Khan: @PaulFerraro That can't map properly, it needs to map onto one resource
[18:00] Paul Ferraro: e.g. transport=TRANSPORT,type=UDP becomes transport=UDP
[18:00] Kabir Khan: ok, I see
in that case I can try to take a look
[18:01] Paul Ferraro: so - it needs more context than just the address
[18:01] Kabir Khan: and let me guess, that is not available at the moment from AliasEntry
[18:01] Paul Ferraro: right



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 13:12:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 30 Sep 2015 13:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.27459.1443633120629@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-5290:
--------------------------------

    Assignee: Paul Ferraro  (was: Kabir Khan)


> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 13:12:00 2015
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 30 Sep 2015 13:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to
 freeze the UI
In-Reply-To: <JIRA.12582662.1440591123000@Atlassian.JIRA>
References: <JIRA.12582662.1440591123000@Atlassian.JIRA>
	<JIRA.12582662.1440591123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582662.1440591123000.27470.1443633120860@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113927#comment-13113927 ] 

Kabir Khan commented on WFLY-5290:
----------------------------------

Assigned back to Paul since the fix for this will be in WFCORE

> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
>                 Key: WFLY-5290
>                 URL: https://issues.jboss.org/browse/WFLY-5290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Jan Ka??k
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Sep 30 13:18:00 2015
From: issues at jboss.org (Mark Wardell (JIRA))
Date: Wed, 30 Sep 2015 13:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5434) HttpSession invalidate()
 throws IllegalStateException: Transaction is not in a valid state
In-Reply-To: <JIRA.12586735.1443633426000@Atlassian.JIRA>
References: <JIRA.12586735.1443633426000@Atlassian.JIRA>
	<JIRA.12586735.1443633426798@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586735.1443633426000.27482.1443633480125@Atlassian.JIRA>

Mark Wardell created WFLY-5434:
----------------------------------

             Summary: HttpSession invalidate() throws IllegalStateException: Transaction is not in a valid state
                 Key: WFLY-5434
                 URL: https://issues.jboss.org/browse/WFLY-5434
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.0.0.CR2
            Reporter: Mark Wardell
            Assignee: Jason Greene
         Attachments: exception.txt

Running standalone HA configuration with single sign on enabled in undertow configuration
Two wars deployed each marked as distributable

If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call:

08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on.
        at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388)
        at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357)
        at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
...
        at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438)
        at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176)
        at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
        at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27)


(full stack trace attached)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 13:25:00 2015
From: issues at jboss.org (Mark Wardell (JIRA))
Date: Wed, 30 Sep 2015 13:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5434) HttpSession invalidate()
 throws IllegalStateException: Transaction is not in a valid state
In-Reply-To: <JIRA.12586735.1443633426000@Atlassian.JIRA>
References: <JIRA.12586735.1443633426000@Atlassian.JIRA>
	<JIRA.12586735.1443633426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586735.1443633426000.27496.1443633900172@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Wardell updated WFLY-5434:
-------------------------------
    Steps to Reproduce: 
Reproduced in a project here: 
* https://github.com/mbw-ahc/wf10issue
* servlet-security copied from the quick starts but with <distributable/> added to the configuration
* logoutwar has a simple servlet that executes the session invalidate on get
* standalone-ha-sso.xml is the configuration file used, it is just standalone-ha with sso configured, plus some security domain added from the quick start.
	
Steps
	run wildfly 10.0.0.CR2 with the standalone-ha-sso.xml configuration
	setup the quickstart as per the instructions on the quickstart https://github.com/wildfly/quickstart/tree/10.x/servlet-security
	deploy the wars
	open a browser, 
		To login from one war, open the URL to http://localhost:8080/wildfly-servlet-security/SecuredServlet
		To invalidate the session from the other war, open http://localhost:8080/logoutwar/logout
		The stack trace should be visible in the console log.

  was:
Reproduced in a project here: 
	https://github.com/mbw-ahc/wf10issue
	servlet-security copied from the quick starts but with <distributable/> added to the configuration
	logoutwar has a simple servlet that executes the session invalidate on get
	standalone-ha-sso.xml is the configuration file used, it is just standalone-ha with sso configured, plus some security domain added from the quick start.
	
Steps
	run wildfly 10.0.0.CR2 with the standalone-ha-sso.xml configuration
	setup the quickstart as per the instructions on the quickstart https://github.com/wildfly/quickstart/tree/10.x/servlet-security
	deploy the wars
	open a browser, 
		To login from one war, open the URL to http://localhost:8080/wildfly-servlet-security/SecuredServlet
		To invalidate the session from the other war, open http://localhost:8080/logoutwar/logout
		The stack trace should be visible in the console log.



> HttpSession invalidate() throws IllegalStateException: Transaction is not in a valid state
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5434
>                 URL: https://issues.jboss.org/browse/WFLY-5434
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.CR2
>            Reporter: Mark Wardell
>            Assignee: Jason Greene
>         Attachments: exception.txt
>
>
> Running standalone HA configuration with single sign on enabled in undertow configuration
> Two wars deployed each marked as distributable
> If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call:
> 08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on.
>         at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388)
>         at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357)
>         at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> ...
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438)
>         at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176)
>         at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
>         at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27)
> (full stack trace attached)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 13:25:00 2015
From: issues at jboss.org (Mark Wardell (JIRA))
Date: Wed, 30 Sep 2015 13:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5434) HttpSession invalidate()
 throws IllegalStateException: Transaction is not in a valid state
In-Reply-To: <JIRA.12586735.1443633426000@Atlassian.JIRA>
References: <JIRA.12586735.1443633426000@Atlassian.JIRA>
	<JIRA.12586735.1443633426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586735.1443633426000.27500.1443633900252@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Wardell updated WFLY-5434:
-------------------------------
    Steps to Reproduce: 
Reproduced in a project here: 
* https://github.com/mbw-ahc/wf10issue
* servlet-security copied from the quick starts but with <distributable/> added to the configuration
* logoutwar has a simple servlet that executes the session invalidate on get
* standalone-ha-sso.xml is the configuration file used, it is just standalone-ha with sso configured, plus some security domain added from the quick start.
	
Steps
* 	run wildfly 10.0.0.CR2 with the standalone-ha-sso.xml configuration
* 	setup the quickstart as per the instructions on the quickstart https://github.com/wildfly/quickstart/tree/10.x/servlet-security
* 	deploy the wars
* 	open a browser, 
		To login from one war, open the URL to http://localhost:8080/wildfly-servlet-security/SecuredServlet
		To invalidate the session from the other war, open http://localhost:8080/logoutwar/logout
		The stack trace should be visible in the console log.

  was:
Reproduced in a project here: 
* https://github.com/mbw-ahc/wf10issue
* servlet-security copied from the quick starts but with <distributable/> added to the configuration
* logoutwar has a simple servlet that executes the session invalidate on get
* standalone-ha-sso.xml is the configuration file used, it is just standalone-ha with sso configured, plus some security domain added from the quick start.
	
Steps
	run wildfly 10.0.0.CR2 with the standalone-ha-sso.xml configuration
	setup the quickstart as per the instructions on the quickstart https://github.com/wildfly/quickstart/tree/10.x/servlet-security
	deploy the wars
	open a browser, 
		To login from one war, open the URL to http://localhost:8080/wildfly-servlet-security/SecuredServlet
		To invalidate the session from the other war, open http://localhost:8080/logoutwar/logout
		The stack trace should be visible in the console log.



> HttpSession invalidate() throws IllegalStateException: Transaction is not in a valid state
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5434
>                 URL: https://issues.jboss.org/browse/WFLY-5434
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.CR2
>            Reporter: Mark Wardell
>            Assignee: Jason Greene
>         Attachments: exception.txt
>
>
> Running standalone HA configuration with single sign on enabled in undertow configuration
> Two wars deployed each marked as distributable
> If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call:
> 08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on.
>         at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388)
>         at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357)
>         at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> ...
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438)
>         at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176)
>         at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
>         at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27)
> (full stack trace attached)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 13:26:00 2015
From: issues at jboss.org (Mark Wardell (JIRA))
Date: Wed, 30 Sep 2015 13:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5434) HttpSession invalidate()
 throws IllegalStateException: Transaction is not in a valid state
In-Reply-To: <JIRA.12586735.1443633426000@Atlassian.JIRA>
References: <JIRA.12586735.1443633426000@Atlassian.JIRA>
	<JIRA.12586735.1443633426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586735.1443633426000.27502.1443633960122@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Wardell updated WFLY-5434:
-------------------------------
    Steps to Reproduce: 
Reproduced in a project here: 
* https://github.com/mbw-ahc/wf10issue
* servlet-security copied from the quick starts but with <distributable/> added to the configuration
* logoutwar has a simple servlet that executes the session invalidate on get
* standalone-ha-sso.xml is the configuration file used, it is just standalone-ha with sso configured, plus some security domain added from the quick start.
	
Steps
* 	run wildfly 10.0.0.CR2 with the standalone-ha-sso.xml configuration
* 	setup the quickstart as per the instructions on the quickstart https://github.com/wildfly/quickstart/tree/10.x/servlet-security
* 	deploy the wars
* 	open a browser, 
**		To login from one war, open the URL to http://localhost:8080/wildfly-servlet-security/SecuredServlet
**		To invalidate the session from the other war, open http://localhost:8080/logoutwar/logout
**		The stack trace should be visible in the console log.

  was:
Reproduced in a project here: 
* https://github.com/mbw-ahc/wf10issue
* servlet-security copied from the quick starts but with <distributable/> added to the configuration
* logoutwar has a simple servlet that executes the session invalidate on get
* standalone-ha-sso.xml is the configuration file used, it is just standalone-ha with sso configured, plus some security domain added from the quick start.
	
Steps
* 	run wildfly 10.0.0.CR2 with the standalone-ha-sso.xml configuration
* 	setup the quickstart as per the instructions on the quickstart https://github.com/wildfly/quickstart/tree/10.x/servlet-security
* 	deploy the wars
* 	open a browser, 
		To login from one war, open the URL to http://localhost:8080/wildfly-servlet-security/SecuredServlet
		To invalidate the session from the other war, open http://localhost:8080/logoutwar/logout
		The stack trace should be visible in the console log.



> HttpSession invalidate() throws IllegalStateException: Transaction is not in a valid state
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5434
>                 URL: https://issues.jboss.org/browse/WFLY-5434
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.CR2
>            Reporter: Mark Wardell
>            Assignee: Jason Greene
>         Attachments: exception.txt
>
>
> Running standalone HA configuration with single sign on enabled in undertow configuration
> Two wars deployed each marked as distributable
> If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call:
> 08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on.
>         at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388)
>         at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357)
>         at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> ...
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438)
>         at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176)
>         at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
>         at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27)
> (full stack trace attached)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 13:31:00 2015
From: issues at jboss.org (Mark Wardell (JIRA))
Date: Wed, 30 Sep 2015 13:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5434) HttpSession invalidate()
 throws IllegalStateException: Transaction is not in a valid state
In-Reply-To: <JIRA.12586735.1443633426000@Atlassian.JIRA>
References: <JIRA.12586735.1443633426000@Atlassian.JIRA>
	<JIRA.12586735.1443633426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586735.1443633426000.27518.1443634260260@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Wardell updated WFLY-5434:
-------------------------------
    Description: 
Running standalone HA configuration with single sign on enabled in undertow configuration
Two wars deployed each marked as distributable

If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call:

{code}
08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction {xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on.
        at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388)
        at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357)
        at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
...
        at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438)
        at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176)
        at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
        at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27)
{code}
(full stack trace attached)

  was:
Running standalone HA configuration with single sign on enabled in undertow configuration
Two wars deployed each marked as distributable

If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call:

08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on.
        at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388)
        at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357)
        at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
...
        at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438)
        at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176)
        at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
        at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27)


(full stack trace attached)



> HttpSession invalidate() throws IllegalStateException: Transaction is not in a valid state
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5434
>                 URL: https://issues.jboss.org/browse/WFLY-5434
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.CR2
>            Reporter: Mark Wardell
>            Assignee: Jason Greene
>         Attachments: exception.txt
>
>
> Running standalone HA configuration with single sign on enabled in undertow configuration
> Two wars deployed each marked as distributable
> If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call:
> {code}
> 08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction {xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on.
>         at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388)
>         at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357)
>         at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> ...
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438)
>         at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176)
>         at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
>         at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27)
> {code}
> (full stack trace attached)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 14:24:00 2015
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 30 Sep 2015 14:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1966) Specify logger name for
 LogRecord in JDKLogImpl
In-Reply-To: <JIRA.12586670.1443619845000@Atlassian.JIRA>
References: <JIRA.12586670.1443619845000@Atlassian.JIRA>
	<JIRA.12586670.1443619845000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586670.1443619845000.27593.1443637440156@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1966:
---------------------------
    Fix Version/s: 3.6.6


> Specify logger name for LogRecord in JDKLogImpl
> -----------------------------------------------
>
>                 Key: JGRP-1966
>                 URL: https://issues.jboss.org/browse/JGRP-1966
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.6.6
>            Reporter: George Zalizko
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.6.6
>
>
> I use Spring Boot with logback.
> For logging I have pattern:
> {code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code}
> And in console I see: 
> {code}
> 16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN  unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code}
> This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger"
> Actually I don't know is it done specially or not, but I can't find any comments/solutions for that. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 15:55:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 30 Sep 2015 15:55:00 -0400 (EDT)
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.27803.1443642900471@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved ISPN-5800 to WFLY-5436:
------------------------------------------

          Project: WildFly  (was: Infinispan)
              Key: WFLY-5436  (was: ISPN-5800)
         Workflow: GIT Pull Request workflow   (was: GIT Pull Request with Triage workflow)
      Component/s: Clustering
                       (was: Configuration)
    Fix Version/s:     (was: 8.0.0.Final)
                       (was: 8.0.0.Alpha2)


> 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: Tristan Tarrant
>            Priority: Critical
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 15:55:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 30 Sep 2015 15:55:00 -0400 (EDT)
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.27811.1443642900656@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned WFLY-5436:
----------------------------------

    Assignee: Paul Ferraro  (was: Tristan Tarrant)


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 16:07:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 30 Sep 2015 16:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-300) Absence of key-store-credential
	NPEs
In-Reply-To: <JIRA.12586712.1443627620000@Atlassian.JIRA>
References: <JIRA.12586712.1443627620000@Atlassian.JIRA>
	<JIRA.12586712.1443627620000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586712.1443627620000.27830.1443643620185@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned ELY-300:
-------------------------------

    Assignee: David Lloyd  (was: Darran Lofthouse)


> Absence of key-store-credential NPEs
> ------------------------------------
>
>                 Key: ELY-300
>                 URL: https://issues.jboss.org/browse/ELY-300
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Kabir Khan
>            Assignee: David Lloyd
>             Fix For: 1.1.0.Alpha1
>
>
> Trying to parse
> {code}
> <authentication-client xmlns="urn:elytron:1.0">
>     <key-stores>
>         <key-store name="test" type="PasswordFile">
>             <file name="keystore/xml-client-keystore-credential-test.keystore"/>
>             <!--<key-store-credential key-store-name="test" alias="test-alias"/>-->
>         </key-store>
>     </key-stores>
> </authentication-client>
> {code}
> I end up with 
> {code}
> java.lang.NullPointerException
> 	at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1082)
> 	at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1067)
> 	at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$115(ElytronXmlParser.java:709)
> 	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$4/1929600551.create(Unknown Source)
> 	at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:47)
> 	at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:30)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$106(ElytronXmlParser.java:425)
> 	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$5/1053782781.create(Unknown Source)
> 	at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$113(ElytronXmlParser.java:474)
> 	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$6/2012232625.create(Unknown Source)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRulesType$88(ElytronXmlParser.java:242)
> 	at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$7/627150481.create(Unknown Source)
> 	at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
> 	at org.wildfly.security.auth.client.XmlClientKeyStoreCredentialTest.testKeystoreCredential(XmlClientKeyStoreCredentialTest.java:110)
> {code}
> This appears to be because the passwordFactory is only instantiated when parsing the key-store-credential element



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 16:09:00 2015
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Sep 2015 16:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-910) Add an Undertow SPNEGO
 authentication mechanism
In-Reply-To: <JIRA.12584412.1441807528000@Atlassian.JIRA>
References: <JIRA.12584412.1441807528000@Atlassian.JIRA>
	<JIRA.12584412.1441807528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584412.1441807528000.27835.1443643740129@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-910:
---------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1267738
        Bugzilla Update: Perform


> Add an Undertow SPNEGO authentication mechanism
> -----------------------------------------------
>
>                 Key: SECURITY-910
>                 URL: https://issues.jboss.org/browse/SECURITY-910
>             Project: PicketBox 
>          Issue Type: Feature Request
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_3_0_0_CR1
>
>
> Undertow does contain an SPNEGO authentication mechanism however this is not compatible with the LoginModule approach of JBoss Negotiation so an alternative mechanism is required here.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 16:19:00 2015
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 30 Sep 2015 16:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-301)
 SetKeyStoreCredentialAuthenticationConfiguration does not translate
 passwords before using them
In-Reply-To: <JIRA.12586757.1443644301000@Atlassian.JIRA>
References: <JIRA.12586757.1443644301000@Atlassian.JIRA>
	<JIRA.12586757.1443644301281@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586757.1443644301000.27860.1443644340147@Atlassian.JIRA>

David Lloyd created ELY-301:
-------------------------------

             Summary: SetKeyStoreCredentialAuthenticationConfiguration does not translate passwords before using them
                 Key: ELY-301
                 URL: https://issues.jboss.org/browse/ELY-301
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.Alpha1


See description.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 17:17:00 2015
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 30 Sep 2015 17:17:00 -0400 (EDT)
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.27918.1443647820123@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-5436:
-------------------------------
    Git Pull Request:   (was: https://github.com/infinispan/infinispan/pull/3516)


> 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
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 18:28:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 30 Sep 2015 18:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-666) Log file validation should
 check if a path is absolute if a relative-to is defined
In-Reply-To: <JIRA.12569102.1429639405000@Atlassian.JIRA>
References: <JIRA.12569102.1429639405000@Atlassian.JIRA>
	<JIRA.12569102.1429639405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569102.1429639405000.28010.1443652080126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFCORE-666.
--------------------------------
    Resolution: Out of Date


This was fixed at some point likely with the of org.jboss.logmanager:log4j-jboss-logmanager:1.1.2.Final.

> Log file validation should check if a path is absolute if a relative-to is defined
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-666
>                 URL: https://issues.jboss.org/browse/WFCORE-666
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The {{path}} attribute on a file should be validated to not be absolute if a {{relative-to}} attribute was also defined.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 18:29:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 30 Sep 2015 18:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-666) Log file validation should
 check if a path is absolute if a relative-to is defined
In-Reply-To: <JIRA.12569102.1429639405000@Atlassian.JIRA>
References: <JIRA.12569102.1429639405000@Atlassian.JIRA>
	<JIRA.12569102.1429639405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569102.1429639405000.28012.1443652140318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reopened WFCORE-666:
----------------------------------


Wrong issue closed.

> Log file validation should check if a path is absolute if a relative-to is defined
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-666
>                 URL: https://issues.jboss.org/browse/WFCORE-666
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The {{path}} attribute on a file should be validated to not be absolute if a {{relative-to}} attribute was also defined.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 18:29:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 30 Sep 2015 18:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't
 display messages with per-deployment logging
In-Reply-To: <JIRA.12500124.1378398130000@Atlassian.JIRA>
References: <JIRA.12500124.1378398130000@Atlassian.JIRA>
	<JIRA.12500124.1378398130000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500124.1378398130000.28022.1443652140517@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFCORE-478.
--------------------------------
    Resolution: Out of Date


This was fixed at some point likely with the of org.jboss.logmanager:log4j-jboss-logmanager:1.1.2.Final.

> log4j ConsoleAppender won't display messages with per-deployment logging
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-478
>                 URL: https://issues.jboss.org/browse/WFCORE-478
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Add the following log4j.properties file to a deployment and try to log.
> {code}
> # Root logger option
> log4j.rootLogger=INFO, stdout
> # Direct log messages to stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.Target=System.out
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 18:37:00 2015
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 30 Sep 2015 18:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-78) Requirement to ser JBOSS_HOME
 as soon as commands are executed
In-Reply-To: <JIRA.12581878.1439998372000@Atlassian.JIRA>
References: <JIRA.12581878.1439998372000@Atlassian.JIRA>
	<JIRA.12581878.1439998372000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581878.1439998372000.28044.1443652620466@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBASMP-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned JBASMP-78:
-----------------------------------

    Assignee:     (was: James Perkins)


> Requirement to ser JBOSS_HOME as soon as commands are executed
> --------------------------------------------------------------
>
>                 Key: JBASMP-78
>                 URL: https://issues.jboss.org/browse/JBASMP-78
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: common
>    Affects Versions: 7.7.Final
>         Environment: This at least happens on Windows Machines, Haven't tried on Linux/Unix based machines.
>            Reporter: Christofer Dutz
>
> If I run jboss-as:run without any configuration and no JBoss installed, the plugin correctly downloads JBoss and unpacks it in my ear projects target directory. It also correctly starts the server and tries to deploy the application. Unfortunately I need to do some configuration first, so I added some "before-deployment" commands. Now the build fails with a message, that the JBOSS_HOME variable isn't set. As soon as I set it to the "target/jboss-as-run/jboss-as-7.1.1.Final" it is able to continue. Would be good however if the plugin could already ensure the variable from being set.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 18:47:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 30 Sep 2015 18:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5415) wildfly-init-debian.sh
 overwrites previous log
In-Reply-To: <JIRA.12586197.1443205612000@Atlassian.JIRA>
References: <JIRA.12586197.1443205612000@Atlassian.JIRA>
	<JIRA.12586197.1443205612000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586197.1443205612000.28099.1443653220652@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-5415.
-----------------------------
    Resolution: Rejected


Configure logging in logging subsystem to log to server.log only and not also to console. 
This way you wont lose anything and it will also perform better.

> wildfly-init-debian.sh overwrites previous log
> ----------------------------------------------
>
>                 Key: WFLY-5415
>                 URL: https://issues.jboss.org/browse/WFLY-5415
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 9.0.1.Final
>         Environment: Wildfly 9.0.1 Final on Ubuntu 14.04 LTS running the Zanata (zanata.org) translations platform.
>            Reporter: Elizabeth K. Joseph
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> We had to restart Wildfly on our Ubuntu 14.04 LTS server due to some issues with the application on top of it, and during the restart the init script wiped out our old logs and replaced them with the new logs, leaving us with none of the debugging information needed to track down our problem.
> It looks like this line is to blame in bin/init.d/wildfly-init-debian.sh:
> cat /dev/null > "$JBOSS_CONSOLE_LOG"
> Currently using wildfly-9.0.1.Final.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 18:48:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 30 Sep 2015 18:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5366) Startup success detection
 mechanism fails if JBOSS_HOME and jboss.server.base.dir are set
 differently.
In-Reply-To: <JIRA.12585389.1442584310000@Atlassian.JIRA>
References: <JIRA.12585389.1442584310000@Atlassian.JIRA>
	<JIRA.12585389.1442584310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585389.1442584310000.28120.1443653280645@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-5366:
---------------------------------

    Assignee:     (was: Tomaz Cerar)


> Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5366
>                 URL: https://issues.jboss.org/browse/WFLY-5366
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.CR1
>         Environment: Linux/Debian
>            Reporter: Thorsten Moeller
>             Fix For: Awaiting Volunteers
>
>
> If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.
> Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.
> I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Sep 30 18:48:00 2015
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 30 Sep 2015 18:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5366) Startup success detection
 mechanism fails if JBOSS_HOME and jboss.server.base.dir are set
 differently.
In-Reply-To: <JIRA.12585389.1442584310000@Atlassian.JIRA>
References: <JIRA.12585389.1442584310000@Atlassian.JIRA>
	<JIRA.12585389.1442584310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585389.1442584310000.28123.1443653280694@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-5366:
------------------------------
    Fix Version/s: Awaiting Volunteers


> Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5366
>                 URL: https://issues.jboss.org/browse/WFLY-5366
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.CR1
>         Environment: Linux/Debian
>            Reporter: Thorsten Moeller
>             Fix For: Awaiting Volunteers
>
>
> If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.
> Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.
> I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

